Issueの対応が早くていい奴だと思っていたら裏切られた
普通に間違いを指摘していったら、突然情報が改悪された上、それを再指摘したらいきなりブロックされた。
はじまり
IchigoJam の命令の詳細な情報が書かれた便利なリポジトリがある。
※IchigoJamはjig.jpの登録商標です。
fu-sen/IchigoJam-BASIC: 🍓🅱️ IchigoJam BASIC コマンド一覧 command reference (Japanese)
以下、引用元の「Issue」はこのリポジトリのIssueを表す。
しばらく更新されていないようだったが、情報と実際の挙動の違いを指摘するissueを立ててみたらなんとたったの4時間で修正され、感謝もされた。
FILE の説明が事実と異なる · Issue #3 · fu-sen/IchigoJam-BASIC
積極的な報告と素早い対処
報告したら修正してくれることがわかったので、気づいた点はどんどん指摘していくことにした。
I2CR・I2CW の返り値の説明が無い · Issue #4 · fu-sen/IchigoJam-BASIC
間違いではなく記述が少ないという指摘だったが、約4時間で追加していただけた。
感謝の言葉もあった。
位置の計算式がおかしい · Issue #5 · fu-sen/IchigoJam-BASIC
間違いの指摘をした。約8時間で修正していただけた。
感謝の言葉もあった。
UART typo? · Issue #6 · fu-sen/IchigoJam-BASIC
間違いの指摘ではあるが、仕様の間違いではなく軽微な誤字の指摘である。
約8時間で修正していただけ、感謝の言葉もあった。
いずれもすぐに素直に修正していただけ、特に攻撃的な投稿も無かった。
改悪とブロック
同様に間違いの指摘をした。
UART の記述が 1.4.1 の挙動と異なる · Issue #7 · fu-sen/IchigoJam-BASIC
なんと2時間という早さで対応がされたが、様子がおかしい。
記載修正 (issue #7) · fu-sen/IchigoJam-BASIC@bf7a522
「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と同様にこの記述は無い。
前述の通り、「このとおりに反映」などされていない。
事実に反する記述である。
ただし、
という感謝の言葉もあり、これ以外に攻撃や注意などは投稿されていない。
とりあえず、仕様の再検証を行い、再び指摘を行った。
UART の記述が 1.4.1 の動作と異なる · Issue #8 · fu-sen/IchigoJam-BASIC
すると、ひどいことが起きた。
管理者によるコメントの連投がなされた上、Issueの新規作成や既存のIssueへのコメントができない設定にされた (ブロックされた) のである。
これらは、管理者による最初の返信からブロックまで、全て私が通知を見ていない間に行われた。
一方的に勝手な主張をされた上、反論を封じられたということである。
管理者が一方的に投稿してきた内容を、詳しくみていこう。
再指摘から約2.5時間で投稿されており、Pull Request を要求しているような内容である。
通常の状態であればもちろん協力したいところであるが、残念ながら現在はそもそもforkができない状態であるため、「Pull Request していただく事はできますか?」への回答は非常に不本意ながら「いいえ」である。
なお、この投稿から管理者による最後の投稿までは約8.5時間であり、この短い時間で「Pull Request が欲しい」から「(forkさせないことで) Pull Requestさせない」に手のひらを返しやがったと考えられる。
ただし、これはあくまで「考えられる」だけであり、
実際にforkができなくなる設定をしたのは最終投稿より後である
Issueの投稿を拒否する設定によりforkまでできなくなることを知らなかった
形だけPull Requestを要求するような投稿をしているが、もともとPull Requestを受け入れる気なんか無い
など別の可能性も考えられることに注意したい。
先ほどの、自分には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 になっているように見え」というのは否定できない。
「検証不足という感じがします。」というのも、主観的なことなので否定はできない。
これはおかしいと思う。
自分も、発明者の記事や実機での検証に基づいて指摘を投稿している。
今回議題となっている UART のページにおいても、「1.2b62 のみ」という特定のバージョン (しかもベータ版!) だけの挙動が掲載されており、「バージョンや環境で動作が細かく変わってくる事」はIssueを立ててはいけない理由にはならないと思う。
さらに、気付いた改善点1個につき1個だけIssueを立てており、やみくもに issues を建て」ているつもりも無い。
ついでに、「健勝」というのもおかしい。「検証」の間違いだろう。
いいえ。
自分は、
#7「LFが出力される」
#8「0x0A が出力されていました」「その他のモードでも改行時同じデータが出力される」
と、一貫して「改行はLF」という主張をしている。(CR+LFが出力されるモードを除く)
本当だろうか?
検証したいところだが、具体的にどのようなパラメータによってどう変わるかが書かれておらず、有効な (仕様が定義されている) 入力を与えた場合のこととも限らないため、「どんなパラメータでも変わらない」ことを証明するのは悪魔の証明となり、難しいかもしれない。
数値だけでなく文字列を入力することまで考えると、その考えられるパターン数は非常に大きくなり、全パターンを調査するのは不可能であるといえるだろう。
「変わる可能性があります」などではなく、はっきりと「変わります」と主張するのであれば、明確にどのバージョンにおいてどのようなパラメータを設定するとどう変わるのかを述べるべきではないだろうか。
これは管理人さんの行動を書いているだけであり、間違ってはいないだろう。
主観の話であり否定はできないが、私とは違う意見である。
「CR を LF に変換して処理する」ということは、CR は IchigoJam にとって改行コードとしては変なものであり、通常用いる LF に変換したい、と考えられる。
よって、LF を用いるのが仕様的にしっくりくる。
これは明確に事実に反する。
通常のビデオ出力を用いるモードにおいても、UART4 の実行後も、画面表示
は行われた。
さらに、実際に「画面表示を行わないモード」である UART9 を実行すると、液晶を用いるモード (SWITCH 1) であっても、画面への出力はされなかった。
よって、「UART とは関係なく、SWITCH の仕様」というのは、明確に誤りである。
これまでのIssueでは、
と、きちんと検証を行った上で対応していただけている。(少なくとも、そのように主張している)
どうしてこんなちょっと試せばすぐわかるような嘘を急についてきたのか、理解に苦しむ。
また、このリポジトリには SWITCH についての解説もある。
そのため、もし仮にこのIssueの対象外であったとしても、issues (全体) の対象外、というのはおかしいと考えられる。
「無視されます」じゃない。
お前が事実に反することを根拠に勝手に無視するんだろ。
これらの投稿からさらに約1時間後の投稿である。
改行コードについては認められたようで、よかった。
しかし、この記事の執筆時点において、残念ながらモード4で「画面出力を行わない」という嘘は残ってしまっている。
早急に改善されるよう祈っておこう。
自分も発明者の記事の確認や実機での検証を行った上でIssueを投稿している。
さらに、IchigoJam Advent Calendar にも以下のように多くの記事を投稿している。
よって、自分も「IchigoJam にたずさわる皆さん」に含まれてしかるべきであると考える。
繰り返しになるが、自分は発明者の記事の確認や実機での検証を行った上でIssueを投稿している。
むしろ、報告した内容に反し、わざわざ正しかった記述を間違った情報に書き換えて破損させたのはお前だろ。
このような、一旦は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
このページには、以下の提案が書かれている。
実機による検証結果などの根拠に基づき、その根拠を提示し、データの改善のための提案をしているだけであるにもかかわらず、一方的に「情報を (中略) 破損させようとしている」呼ばわりされたり、ちょっと検証すればすぐにわかるような事実に反する主張を根拠に「無視されます」とされたりするのは、「敬意を払う」に違反していると判断する。
一旦はPull Requestを要求するかのような投稿をしておきながら、短い時間で手のひらを返し、一方的な主張を並べ、反論とPull Request (のためのfork) を封じるというのは、更新をチェックする間隔が長い人への配慮が無く、「他の人の立場になって考えてみて」に違反していると判断する。
また、いきなり反論や新規Issueの作成を封じるというのは、「安心して投稿し、ディスカッションに参加し、さまざまなアイデアを共有できるコミュニティにする」にも違反していると判断する。
Pull Request (のためのfork) も封じられたため、「新しいコラボレーター (中略) を受け入れてください」にも違反していると判断する。
私は、今回の件で感情を害された。
そのため、何かまたは何ものかがお客様の感情を害した場合の記述に沿い、アクティビティがポリシーに違反していると思うので、GitHub Support にお知らせする。
付録:各バージョンにおける UART 4 の動作の確認
改行コードについては LF ということで決着がついているので、検証は省略する。
現在うちにある UART コマンドに対応した IchigoJam の各バージョンにおいて、UART 4 を実行した後でも、画面に PRINT で出力した内容が表示されるかを確認した。
その結果、今回検証を行った全バージョンにおいて、SWITCH コマンドとは関係なく、UART 4 を実行した後でも、PRINT で出力した内容が画面に表示された。
このとき、SWITCH コマンドは用いていないため、管理人の「モード4においてPRINTした内容が画面に出力されるのは、UART とは関係なく、SWITCH の仕様だ」という主張が事実に反することが確認できる。
なお、「プログラムによりそれっぽい内容をわざと出力する」「出力内容を手動で加工してから画面を撮影する」という不正ができないよう、電源投入時からの様子をビデオ撮影し、シリアルポートは用いずにキーボードからデータを手動で入力して検証を行った。
IchigoJam BASIC 1.3.1 by jig.jp / IchigoJam S
UART 4 を実行した後でも、PRINT で出力した内容が画面に表示された。
IchigoJam BASIC 1.4.1 by jig.jp / IchigoKamuy
UART 4 を実行した後でも、PRINT で出力した内容が画面に表示された。
IchigoJam BASIC 1.4.3 by jig.jp / IchigoJam Q
UART 4 を実行した後でも、PRINT で出力した内容が画面に表示された。
IchigoJam BASIC 1.5b rv jig.jp / IchigoJam R
UART 4 を実行した後でも、PRINT で出力した内容が画面に表示された。
IchigoJam BASIC 1.5.0D by jig.jp / GIGA IchigoDake
UART 4 を実行した後でも、PRINT で出力した内容が画面に表示された。
IchigoCake BASIC 1.4.1 jig.jp forked by na-s.jp / IchigoCake
UART 4 を実行した後でも、PRINT で出力した内容が画面に表示された。
この記事が気に入ったらサポートをしてみませんか?