「LFが出力される」という指摘をしており、LFが出力されている実験結果も提示しているにもかかわらず、指摘した部分が修正されないどころか、なぜかこれまで正しく「改行コード LF」と書かれていた場所まで「改行コード CR」という間違った記述に改悪されている。
ただし、なぜかモード 10 だけは「改行コード LF」のまま変わっていない。

さらに、モード 4 において、「画面表示を行わない」という記述が勝手に追加されている。
モード 4 においても、モード0～3および5～7と同様に画面には出力されるので、これは誤りである。
このIssue内でリンクを示した IchigoJam 発明者の記事

IchigoJamの高度な使い方、UART編とLC/INPUTバグ修正

においても、モード8～15には「画面表示OFF」という記述があるが、モード4にはモード0～3およびモード5～7と同様にこの記述は無い。

仕様と上記の動作結果があってるので、このとおりに反映いたしました。

Issue #7

前述の通り、「このとおりに反映」などされていない。
事実に反する記述である。
ただし、

細かく調査していただき、ありがとうございます。

Issue #7

という感謝の言葉もあり、これ以外に攻撃や注意などは投稿されていない。

とりあえず、仕様の再検証を行い、再び指摘を行った。

UART の記述が 1.4.1 の動作と異なる · Issue #8 · fu-sen/IchigoJam-BASIC

すると、ひどいことが起きた。

管理者によるコメントの連投がなされた上、Issueの新規作成や既存のIssueへのコメントができない設定にされた (ブロックされた) のである。
これらは、管理者による最初の返信からブロックまで、全て私が通知を見ていない間に行われた。
一方的に勝手な主張をされた上、反論を封じられたということである。

管理者が一方的に投稿してきた内容を、詳しくみていこう。

記載不足になるのだと思いますが、どのように修正すべきかがこの文章ではピンときません。
ファイルを修正して Pull Request していただく事はできますか？修正内容を明確にしていただけると助かります。
（今 IchigoJam に時間をさける状況ではないので……よろしくお願いします）

Issue #8

再指摘から約2.5時間で投稿されており、Pull Request を要求しているような内容である。
通常の状態であればもちろん協力したいところであるが、残念ながら現在はそもそもforkができない状態であるため、「Pull Request していただく事はできますか？」への回答は非常に不本意ながら「いいえ」である。

なお、この投稿から管理者による最後の投稿までは約8.5時間であり、この短い時間で「Pull Request が欲しい」から「(forkさせないことで) Pull Requestさせない」に手のひらを返しやがったと考えられる。
ただし、これはあくまで「考えられる」だけであり、

実際にforkができなくなる設定をしたのは最終投稿より後である
Issueの投稿を拒否する設定によりforkまでできなくなることを知らなかった
形だけPull Requestを要求するような投稿をしているが、もともとPull Requestを受け入れる気なんか無い

など別の可能性も考えられることに注意したい。

> また、モード1、4、5、6、9、12、13、14 において、「改行コード CR」と書かれていますが、IJUtilitiesを用いて確認したところ、例えばモード1において改行時 0x0A が出力されていました。

これに関しては #7 の内容がケースによって CR になってたり、LF になっているように見え、検証不足という感じがします。

Issue #8

先ほどの、自分にはPull Requestを要求しているように見える投稿から約7.5時間後の投稿である。

今回貼った実験結果 (ログ) は、以下のものである。

接続 COM3
送-> RESET<LF>
->受 IchigoJam BASIC 1.4.1 by jig.jp<LF>OK<LF>
送-> UART 0<LF>CLS:PRINT 1<LF>
送-> UART 1<LF>CLS:PRINT 1<LF>
->受 OK<LF>
->受 1<LF>OK<LF>
送-> UART 2<LF>CLS:PRINT 1<LF>
->受 OK<LF>
->受 <13><0c>1<LF>OK<LF>
送-> UART 3<LF>CLS:PRINT 1<LF>
->受 OK<CR><LF>
->受 1<CR><LF>OK<CR><LF>
送-> UART 4<LF>CLS:PRINT 1<LF>
->受 CLS:PRINT 1<LF>
送-> UART 5<LF>CLS:PRINT 1<LF>
->受 UART 5<LF>OK<LF>CLS:PRINT 1<LF>1<LF>OK<LF>
送-> UART 6<LF>CLS:PRINT 1<LF>
->受 UART 6<LF>OK<LF>CLS:PRINT 1<LF><13><0c>1<LF>OK<LF>
送-> UART 7<LF>CLS:PRINT 1<LF>
->受 UART 7<LF>OK<CR><LF>CLS:PRINT 1<CR><LF>1<CR><LF>OK<CR><LF>
送-> UART 8<LF>CLS:PRINT 1<LF>
->受 UART 8<CR><LF>
送-> UART 9<LF>CLS:PRINT 1<LF>
->受 OK<LF>
->受 1<LF>OK<LF>
送-> UART 10<LF>CLS:PRINT 1<LF>
->受 OK<LF>
->受 <13><0c>1<LF>OK<LF>
送-> UART 11<LF>CLS:PRINT 1<LF>
->受 OK<CR><LF>
->受 1<CR><LF>OK<CR><LF>
送-> UART 12<LF>CLS:PRINT 1<LF>
->受 CLS:PRINT 1<LF>
送-> UART 13<LF>CLS:PRINT 1<LF>
->受 UART 13<LF>OK<LF>CLS:PRINT 1<LF>1<LF>OK<LF>
送-> UART 14<LF>CLS:PRINT 1<LF>
->受 UART 14<LF>OK<LF>CLS:PRINT 1<LF><13><0c>1<LF>OK<LF>
送-> UART 15<LF>CLS:PRINT 1<LF>
->受 UART 15<LF>OK<CR><LF>CLS:PRINT 1<CR><LF>1<CR><LF>OK<CR><LF>
切断 COM3

改行として、仕様に沿って「LF」または「CR+LF」が出ており、「CR」単体のケースはここでは存在しない。
よって、「ケースによって CR になってたり、LF になっている」というのは事実に反する。

とはいえ、実験結果としてログを貼るだけで解説を書かなかったのは自分の落ち度かもしれない。
相手の脳内や環境のことはわからないので、「ケースによって CR になってたり、LF になっているように見え」というのは否定できない。
「検証不足という感じがします。」というのも、主観的なことなので否定はできない。

一応ここにある記載は様々な仕様書や実際の健勝に基づいて記載してきたものなので、それを自分の環境では異なるとかでやみくもに issues を建てないで下さい。バージョンや環境で動作が細かく変わってくる事がありますので。

Issue #8

これはおかしいと思う。
自分も、発明者の記事や実機での検証に基づいて指摘を投稿している。
今回議題となっている UART のページにおいても、「1.2b62 のみ」という特定のバージョン (しかもベータ版！) だけの挙動が掲載されており、「バージョンや環境で動作が細かく変わってくる事」はIssueを立ててはいけない理由にはならないと思う。
さらに、気付いた改善点1個につき1個だけIssueを立てており、やみくもに issues を建て」ているつもりも無い。

ついでに、「健勝」というのもおかしい。「検証」の間違いだろう。

改行については CR か LF なのかが環境でバラバラでわからない、という感じでしょうか？

Issue #8

いいえ。
自分は、
#7「LFが出力される」
#8「0x0A が出力されていました」「その他のモードでも改行時同じデータが出力される」
と、一貫して「改行はLF」という主張をしている。(CR+LFが出力されるモードを除く)

UART の第 2 パラメータでも変わります。

Issue #8

本当だろうか？
検証したいところだが、具体的にどのようなパラメータによってどう変わるかが書かれておらず、有効な (仕様が定義されている) 入力を与えた場合のこととも限らないため、「どんなパラメータでも変わらない」ことを証明するのは悪魔の証明となり、難しいかもしれない。
数値だけでなく文字列を入力することまで考えると、その考えられるパターン数は非常に大きくなり、全パターンを調査するのは不可能であるといえるだろう。

「変わる可能性があります」などではなく、はっきりと「変わります」と主張するのであれば、明確にどのバージョンにおいてどのようなパラメータを設定するとどう変わるのかを述べるべきではないだろうか。

まだ CR のままにしておきます。

Issue #8

これは管理人さんの行動を書いているだけであり、間違ってはいないだろう。

第 2 パラメータで「4 改行コード CR を LF に変換して処理する」が存在するので、CR だと仕様的にはしっくりきます。

Issue #8

主観の話であり否定はできないが、私とは違う意見である。
「CR を LF に変換して処理する」ということは、CR は IchigoJam にとって改行コードとしては変なものであり、通常用いる LF に変換したい、と考えられる。
よって、LF を用いるのが仕様的にしっくりくる。

> モード4において、「画面表示を行わない」と書かれていますが、液晶 (SWITCH 1) を用いて確認したところ、PRINTした内容が画面に出力されました。

これについては UART とは関係なく、SWITCH の仕様なので、issues の対象外です。

Issue #8

これは明確に事実に反する。
通常のビデオ出力を用いるモードにおいても、UART4 の実行後も、画面表示
は行われた。

さらに、実際に「画面表示を行わないモード」である UART9 を実行すると、液晶を用いるモード (SWITCH 1) であっても、画面への出力はされなかった。

よって、「UART とは関係なく、SWITCH の仕様」というのは、明確に誤りである。

これまでのIssueでは、

実機確認で公開されている 1.0.1 から 1.5.0 までファイルアクセスなしは FILE() = 0 で返ってくる事を確認しました

Issue #3

書籍を確認したところ、「みんなのIchigoJam入門」より通信の成功 0・失敗 1 との記載でした。（P190 およゔ P194）

Issue #4

と、きちんと検証を行った上で対応していただけている。(少なくとも、そのように主張している)
どうしてこんなちょっと試せばすぐわかるような嘘を急についてきたのか、理解に苦しむ。

また、このリポジトリには SWITCH についての解説もある。
そのため、もし仮にこのIssueの対象外であったとしても、issues (全体) の対象外、というのはおかしいと考えられる。

これは無視されます。

Issue #8

「無視されます」じゃない。
お前が事実に反することを根拠に勝手に無視するんだろ。

デフォルト動作は LF（10 進数 10、16 進数 0A）と確認したので、これで反映します。

Issue #8

これらの投稿からさらに約1時間後の投稿である。
改行コードについては認められたようで、よかった。
しかし、この記事の執筆時点において、残念ながらモード4で「画面出力を行わない」という嘘は残ってしまっている。
早急に改善されるよう祈っておこう。

なお、このテキストは私が製作・公開していますが、長年様々な人が製作した仕様書や実際の検証により、ここまで積み上げられてきたものです。つまりは私のものではなく、IchigoJam にたずさわる皆さんの努力によってここまでの形になったものです。

Issue #8

自分も発明者の記事の確認や実機での検証を行った上でIssueを投稿している。
さらに、IchigoJam Advent Calendar にも以下のように多くの記事を投稿している。

よって、自分も「IchigoJam にたずさわる皆さん」に含まれてしかるべきであると考える。

この情報を一個人によって異なるからと issues を建て破損させようとしている状況にあります。

Issue #8

繰り返しになるが、自分は発明者の記事の確認や実機での検証を行った上でIssueを投稿している。
むしろ、報告した内容に反し、わざわざ正しかった記述を間違った情報に書き換えて破損させたのはお前だろ。

また連続した issues により、私の活動時間を奪われており、悪影響を受けている状況でもあります。そのため、しかるべき対処を行わせていただきました。よろしくお願いいたします。

Issue #8

このような、一旦はPull Requestを要求するような投稿をしておきながら、短い時間で手のひらを返して一方的に事実に反することを含む主張を並べ、反論もPull Request (のためのfork) も封じるような行為が「しかるべき (そうするべき、当然な) 対処」であるとは思えない。
以下のような、もっといい対処法があるはずである。

無視する
IssueやPull Requestは投稿できる状態にしておき、管理者はそれを無視する。
これにより、投稿者は見つけた改善点を投稿することによる自己満足が得られ、管理者は通知を既読にするだけという最低限の労力で済む。
実際の例として、これは zlib.js で行われている。
たとえば、自分が立てたIssue
RawDeflate with FIXED or NONE mode doesn't work well with an 0-byte input · Issue #81 · imaya/zlib.js
は、この記事の執筆時点で1年8ヶ月以上もの間無視され続けている。
投稿に関する具体的なルールを提示する
「悪影響を受けている」と批難するだけでなく、具体的にどの程度の量や形式であれば投稿していいかを明示する。
これは mikanos で行われた。
Issue ではなく Pull Request に関してであるが、
簡易テキストエディタを追加 by mikecat · Pull Request #46 · uchan-nos/mikanos
において、「可能であれば一度に 1 つに抑えて欲しいです。」という方針が示され、のちに「複数のプルリクがあっても、優先順位を明示してくだされば対応しやすかったです。」という方針に変更されている。
また、このリポジトリにおいても、前述の無視を用いた負荷対策も行われているようで、前回Pull Requestがマージされてからこの記事の執筆時点でもうすぐ11ヶ月である。
GitHubの機能でIssueの受付を止める
GitHubには、Issuesを無効化する機能がある。
Issues を無効化する - GitHub Docs
改善点の報告を受け付けたくないのであれば、このような記事を報告内容に沿わずに改悪し、事実に反する内容を含む主張を一方的に並べ、反論とPull Request (のためのfork) を封じるという個人に対する攻撃ではなく、全体に対してIssueの受付を止める、という手段もあるだろう。
ただし、この機能の使用には、既存のIssueも閲覧できなくなり、Pull Requestの受付は止められない、という問題点もある。
GitHubの機能でインタラクションを制限する
GitHubには、コメントおよびIssueやPull Requestの作成を含むインタラクションを制限する機能がある。
リポジトリでの操作を制限する - GitHub Docs
この機能を用いることで、リポジトリへの書き込み権限が無いユーザーからのインタラクションを最大6ヶ月間制限できる。
ただし、指定した期間が経過すると自動で解除されてしまう。
リポジトリをアーカイブする
リポジトリを更新する気が無いのであれば、リポジトリをアーカイブするという選択肢もある。
リポジトリのアーカイブ - GitHub Docs
リポジトリをアーカイブすることにより、IssueやPull Requestなどを変更できなくなる。
さらに、アーカイブされたリポジトリにはアーカイブされているという表示が出るため、単にIssueやPull Requestを無視するよりも改善案を受け付けないという意志が明確になる。
アーカイブの解除も簡単にできるため、IchigoJam の新バージョンが出たときなど、また更新したくなっても大丈夫である。
自分の発言に責任を持ってPull Requestを受け付ける
もちろん、このように短時間で手のひらを返して事実に反する内容を含む主張を一方的に並べ、反論とPull Request (のためのfork) を封じるのではなく、「Pull Request していただく事はできますか？」という投稿をしたことに責任を持ち、Pull Requestの投稿を待つ、という選択肢もあったはずである。

さて、行われた「対処」はGitHub上でのブロックだけとは限らない。
「私の活動時間を奪われており、悪影響を受けている状況」という主張があるため、もしかしたら、民事の損害賠償請求や、威力業務妨害罪かなんかでの刑事告訴などがなされているかもしれない。
記事の執筆時点で訴状などは届いていないものの、この先届くかもしれない。
もちろん、私はこれらも「しかるべき (そうするべき、当然な) 対処」であるとは思えない。
ただし、既にPull Requestを要求するような投稿をしておきながら、短い時間で手のひらを返してPull Request (のためのfork) を封じるという「しかるべき (そうするべき、当然な) 対処」とは思えない対処を受けており、「しかるべき (そうするべき、当然な) 対処」でない対処を他にはされないという保証は無い。

ほら、「常識的」とみなせるアクセスによってアクセス先のサービスの不都合を踏んで障害がおきたことにより逮捕された、という事件もあったし…
岡崎市立中央図書館事件 - Wikipedia
Librahack ：容疑者から見た岡崎図書館事件

そもそも、もし仮に「しかるべき対処を行わせていただきました。」という投稿とともに本当に「しかるべき対処」のみをされた様子のみが観測されていたとしても、「しかるべき対処」ではない対処が行われていないとは限らない。
「しかるべき対処以外は行っていません。」とは書かれていないし。

あ、これを見て思い出したからといって損害賠償請求や刑事告訴をするなよ。
これはフリではないぞ。マジでするなよ。
ガチでフリではないぞ。No means No. だぞ。
もしやったらそれこそ損害賠償請求も考えるぞ。
…とはいえ、これを見ないで行われた損害賠償請求や刑事告訴との区別をつけるのは難しそうか…。
だからといってその脆弱性を狙ってやるなよ。マジでやるなよ。

とりあえず、訴状や警察が来ないよう祈っておく。

おわりに

立てたIssueに対して今までは検証なども含めた素早い誠実な対応をしてくれていた (少なくとも、そのように見えた) にもかかわらず、急に「このとおりに反映いたしました」と称して指摘内容に合わない改悪がなされた。
さらに、それを再指摘すると、一旦はPull Requestを要求するかのような投稿をしておきながら、短時間のうちに手のひらを返し、事実に反する内容を含む一方的な主張を並べられ、反論とPull Request (のためのfork) を封じられた。
「時間をさける状況ではない」という問題に対しては、リポジトリのアーカイブやIssueの無視などのもっとよい対処方法が考えられるにもかかわらず、このような個人攻撃のようにも思える処置がいきなりなされた。
これは私にとって非常にショックで、大変残念だ。

さて、ここで新規Issueの作成ページからリンクされている、GitHubのコミュニティガイドラインを確認してみる。

GitHub コミュニティガイドライン - GitHub Docs

このページには、以下の提案が書かれている。

・広い心で受け入れる - 毎日、新しいユーザーが当社のコミュニティに参加します。経験豊富な開発者もいれば、初心者もいます。他のアイデアや経験レベルを受け入れてください。自分以外の意見にも耳を傾け、新しいコラボレーターや初心者を受け入れてください。
・敬意を払う - 協力的な環境で作業することは、意見の相違が生じる可能性があることを意味します。ただし、批判すべきはアイデアであって、人ではありません。思慮深く建設的な批判を共有し、礼儀正しく接してください。敬意を持って接することができない場合は、一歩下がるか、いくつかのモデレーションツールを使用して緊張状態を緩和することを検討してください。
・共感的になる - GitHub は、その多くが自分とは異なる可能性があるさまざまな背景や視点を持つ人々とのグローバルコミュニティです。他の人の立場になって考えてみて、彼らの気持ちを理解してから対応してください。 GitHub を他の人が安心して投稿し、ディスカッションに参加し、さまざまなアイデアを共有できるコミュニティにするために最善を尽くしてください。

GitHub コミュニティガイドライン

実機による検証結果などの根拠に基づき、その根拠を提示し、データの改善のための提案をしているだけであるにもかかわらず、一方的に「情報を (中略) 破損させようとしている」呼ばわりされたり、ちょっと検証すればすぐにわかるような事実に反する主張を根拠に「無視されます」とされたりするのは、「敬意を払う」に違反していると判断する。

一旦はPull Requestを要求するかのような投稿をしておきながら、短い時間で手のひらを返し、一方的な主張を並べ、反論とPull Request (のためのfork) を封じるというのは、更新をチェックする間隔が長い人への配慮が無く、「他の人の立場になって考えてみて」に違反していると判断する。
また、いきなり反論や新規Issueの作成を封じるというのは、「安心して投稿し、ディスカッションに参加し、さまざまなアイデアを共有できるコミュニティにする」にも違反していると判断する。

Pull Request (のためのfork) も封じられたため、「新しいコラボレーター (中略) を受け入れてください」にも違反していると判断する。

私は、今回の件で感情を害された。
そのため、何かまたは何ものかがお客様の感情を害した場合の記述に沿い、アクティビティがポリシーに違反していると思うので、GitHub Support にお知らせする。