><https://twitter.com/orange_in_spacehttps://pawoo.net/@orange_in_space
たとえばある機能に賛成する理由 A と反対する理由 B があったとして、そのどちらを採用しても事例単体では合理性はあるわけで、人々が知りたいのは何故 A より B を、または B より A を優先するのかというところの判断基準
言語化するというかドキュメント化するみたいな面だと思うけど、それ以前にオイゲン氏にマストドンに関するデザインの一貫性がそもそも存在するのかが疑問って言いたい><
そういうのはおそらく任意のプロジェクトで issue 単位で行われていたりするので、私がほしいのは、そういった理由付けを優先的に正当とみなす理由、つまりメタな基準ですね(それを哲学と言うのでしょうけど)
オイゲン氏、最近謎のtwitter風WebUIみたいなの作ってたけど、あのデザインも各部分の必然性を問い詰められたら説明できるんだか出来ないんだか謎かも>< そもそもなんでTwitter風にする必要があるんだか><
オレンジは自分がひとりで作ったものでも、「そこがどうしてそういう仕様なのか?」と問い詰められたら多くの場合ちゃんと説明できるし、説明できない部分は仕様変えるよ><
それが悪いというつもりはないけど、信念なき個人プロジェクトであれば依存を大きくしすぎるのは個人的には気持ちよくないし、やはり別実装を検討してしまう
まあどこまでいっても(現状では)個人のプロジェクトに過ぎないということなのかな
コミッタ複数いればなおさら
それはそれとして、自分の好みってある程度明示されません? みたいな気持ちがある
試作じゃなければそれは駄目だと思うし、それが駄目じゃない文化ってworse is better的だし、worse is better思想って、なにも考えずに行き当たりばったりで作る文化でしょ>< 結局なにも考えてない><
考えてなさそうというか考えを突き詰めてなさそうというか考えをデバッグしてなさそうというか・・・><
ていうか、オイゲン氏、まともに考えてなさそう><
というか大きめのプロダクトって設計思想というか開発方針みたいなの明示されないものなんですかね(私はそんな大規模な開発したことないのでよくわからん)
Mastodon が必ずしも分散を強い促進しているわけでもないというのも、客観的なデータで明示されてほしさがある
マストドンの設計思想を知るには、これまでどんなissue・PRが何故リジェクトされてきたのか、という情報が重要な気がする。誰かまとめるべきでは。 #dtp
英語を機械翻訳でしか読めない人が「英語の表現がおかしいです(英語)」ってクレームに対して「検討しましたがおかしくないです」って言ったら「は?(英語)」ってなるじゃん?>< しかもクレームの英語すら読めていないようであればなおさらかも><
基本的にはそうでも、今回みたいに翻訳そのものがおかしいっていう話に対して、現地語ネイティブのクレームに対して、それこそ機械翻訳でしか読めないレベルの人が謙虚にならずに却下するのは別問題かも><
翻訳に限らずサポート窓口全般に言えるんですが、日本語と英語どっちで書くのがいいんだと思うことが稀によくある(場合によっては併記する)
異音><
ダムの場所わからない・・・><
思考の /dev/null