Information: コードPRのレビュー期間

また、プロセスはコミュニティ中心のリポジトリ、つまり組織の変化に近いPRを念頭に置いて作成されているという印象もありました。

同意しましたが、コードは組織の仕組みを変更するルールを実装していると見なすことができますが、コーディング方法に対する厳しい制限は実行可能ではありません。 それは開発を実質的に停止させるでしょう。

たぶん、これについてプロセスをより明確にするので、コードPRには適用されませんか？

できるだけ早く？ では、プルリクエストまたは発行を開いた直後にマージするのが理想的ですか？ 対話のためのウィンドウが必要ですか？

私は即座に可能性を超えていると主張したいと思います。 :-)レビュー担当者が十分な情報に基づいてレビューを行えるようにする必要がありますが、レビュー担当者はすでにそれを行う時間が必要であり、実行する前にマージが行われないため、「即座に」は単なる架空のものです。

したがって、 @ megothに完全に同意するわけではありません。コードの変更には論争があるため、プロセスをコードに適用することはできません。

ただし、リビジョンシステムを使用することの全体的なポイントは、コードの変更が元に戻せないことではないことにも注意してください。 コードの変更が完全なリリースになる前ではありませんが、元に戻すことが本当に大きな問題であり、さらに時間がかかります。

ここで重要なのは、各PR（コード用かどうかに関係なく）をマージする前に保持する必要がある期間について、厳密なルールは実際にはあり得ないということです。

多くのコード変更と多くの人間向けのドキュメント変更は物議を醸すものではなく、PRの提出と「修正されたタイプミス」のようなマージの間に14日または3日または3時間の遅延を強制する理由はありません、ハイパーリンクからハイパーリンクへ」..。

PRは通常、変更されるものに精通している誰かがレビューする必要があります-それがコードであるかどうかは関係ありません。 「wOR（（x and / or y）AND z）は、このリポジトリ/ファイル/その他のすべてのPRをレビューします」のように言うのは理にかなっているようです。レビューの時間枠は、レビュー担当者のワークロードによって大きく異なる可能性があります。今の瞬間とPRターゲット！

潜在的に論争の的となる変更（あらゆる種類の）は、それらのレビュー担当者がそのように気付く必要があります。レビュー担当者は、あらゆる種類の「上位」を含む、より広範なレビューを要求することを信頼する必要があります。

私が一定期間を選択する理由は、1）問題とプルリクエストが十分に速く処理されない2）問題とプルリクエストが十分に公開されていないため、入力と正当性を与える機会を与えることについての会話があったためです。結果として疑問視されている提案。 明示的に書き留めないということは、Solidに長い間取り組んでいる人々が、コミュニティへの参加をオープンで透明な環境ではなくする、暗黙のエンゲージメントのルールを推測しなければならない新参者よりも有利であることを意味します。

解決策として、すべてのプルリクエストと問題が公開されてから処理されるまでに3日間の期間があると言えますか？

「1つのサイズですべてに対応」するソリューションとして、まだ問題があります。 コードの品質とプロジェクトの進行にいくつかの悪影響があると思います。

まず第一に、少なくとも5年間存在していない暗黙の関与のルールはなく、それは何千ものプロジェクトにわたって非常に標準的な慣行です。 したがって、当然のことながら、開発全体にまったく慣れていない場合は不利になりますが、それはSolidに特有の理由によるものではなく、新しい分野に参入する際には常に学習曲線が必要です。 私が言ったように、Solidのエントリのしきい値が非常に低いことが重要ですが、サーバー開発が、人々がスキルの開発を開始する場所であるかどうか、他の人と緊密に協力する必要のない環境であるかどうかはわかりません。同じコードベースの開発者の方がおそらく適しています。

ほとんどではないにしても、多くのPRは、当然、レビュー期間が3日を超えますが、レビュー担当者の空き状況によって制限されます。 ただし、当然ながら、レビューしやすい比較的小さなPRを目指しています。 早い段階でフィードバックを受け取り、レビュー担当者にとってそれほど難しくないようにするために、これを行うことをお勧めします。 ただし、これは多くの場合、より大きなタスクを解決するには、いくつかの増分PRが必要になることを意味します。 各PRに3日間のレビュー期間が必要な場合、開発が大幅に遅くなります。 それがポリシーだとすれば、私たち開発者は小さなPRを書くのではなく、1つの大きなPRを行うので、それぞれ3日間のレビュー期間を待つ必要がないのではないかと思います。

その結果、レビューが困難な大規模なPR、アジャイル開発からの逸脱、およびより大きなリスクミスがレビュープロセスに潜入します。

この点で他の大規模なプロジェクトが何をしているのかを知りたいと思いますが、私にとっては、万能のアプローチは望ましくも達成可能でもありません。

私はリリースマネージャーなので、言うのは難しいですが、 @ TallTedがそれをサポートすると思います。プロセスは、リリースマネージャーの裁量に大きく依存する必要があります。 リリースマネージャーは、問題に応じて適切な数のレビュー担当者が質問されること、および適切な数のレビュー担当者が承認で応答する前にマージが行われないことを確認する必要があります。変更が要求された場合、レビュープロセスを実施するために適切なブランチがロックされた場合、潜在的に論争のあるPRが何らかの通知手段を通じてコミュニティリーダーの注意を引く場合は発生しません。実際、他のレビュー担当者はそれを行うことを歓迎します。同様に。

コミュニティサポートミーティングの会話からのメモを含めたかっただけです。 これらのポイントは、SolidTeam内のさまざまな人々によって作成されました。

• 3日間のレビュー期間は、SolidWorkの速度を低下させる可能性があります。
• 期間の実際的な利点は何ですか？ 実用的なメリットは、理解して参照できる透明性のある意思決定プロセスを備えた、よりオープンで包括的な環境を作成することです。
• 私たちが解決しようとしている問題は何ですか？ それを解決する他の方法はありますか？ 私たちが本当に解決しようとしているのは、変更が加えられたときに制約があり、彼らには彼らの視点を提供する機会がなかったということです。 時間制限は機会を与える方法です。 包括性を招待するもう1つのアプローチは、提案が、たとえば堅実な提案など、人々が確認できる環境に投稿されるようにすることです。
  –根本ではなく副作用を区別します。
• 包括性と効率性の境界線はどこにありますか？ Do-ocracyは、何かをする人に決めさせる必要があります。 自律性がほとんどないことは、私たちが目指すべきではないもう1つの極端なことです。 Metirocracy –do-ocracy。 これらの理想の実装は、マイノリティにとって有毒である可能性があります。

• 最前線に立ってみましょう。 間違いから何を学ぶことができますか。 以前のようにすべてを行うのではなく、なぜ私たちが行っていることを行っているのかを考えてみましょう。 仕様を自然言語に翻訳する作業を行います。 特にスペックが進化しているときは、最新の状態に保つのは難しいです。 それは非常に長く、人々が読みやすいかもしれませんが、噛むには多すぎるかもしれません。 仕様内のトピックを見つけようとすることを提案します。 仕様の見方を配布する方法を見つけてください。 さまざまな問題を解決するために、さらにチュートリアルを作成してください。 仕様の要素を説明するブログ投稿の余地もあります。 チュアブルティビットにします。

• コミットを削除することはできますが、それらは元に戻すことができますが、元に戻すことは実用的ですか？ コミュニティを元に戻すにはコミットが遅いため、元に戻すにはさらに時間がかかります。 アイテムは以前の決定に基づいて構築されているため、サーバーで元に戻すのは困難です。

• 他のプロジェクトと何ら変わりはありません。 期間の設定は以前の慣行とは異なりますが、私たちがやろうとしているのは別のモデルを構築することであり、以前のモデルは同種のグループによって支配されていたので、過去の慣行を使用するか、最先端を目指しますか思考の？ 前の例から、同じ落とし穴に陥らないようにする方法を学び、何が機能したかを分析できますか？ 私たちは違うことを約束しています–過去にうまくいったことはうまくいきませんでした。

• リポジトリを区別できますか？ もしそうなら、どのように？

• コードはルールとは異なりますか？ ノードSolidサーバーは、コミュニティリポジトリやSolid仕様と同様に、社会に影響を与えます。 では、どのように区別するのですか？ 社会に影響を与えるものを評価することは困難です。特に、その評価を行う専門家が、解釈できる言語ではないために情報にアクセスできない場合はなおさらです。
• ソリッドサーバーは、社会に多大な影響を与える標準的なソフトウェアであるため、コードの決定は大きな影響を及ぼします。
• 個々のプルリクエストはほんの少しの変更であり、そのプロパティはありません。 それらは、変更を段階的に行って、私たちの心を包み込むためだけにあります。 それらは質的および量的に同じではないため、社会の変化と同じではありません。
• 3つの仕様リポジトリとコミュニティリポジトリは、たとえば、定義された最小レビュー期間と割り当てられたレビュー担当者など、より厳密なプロセスを持つ必要があります。 仕様には大きな規範的効果があります。 リポジトリが全体として持つことができる規範的な効果によってリポジトリを区別するための良い方法。 コミュニティレポと堅実なスペックはそのカテゴリーに含まれます。 したがって、透過的なマージを行うとよいでしょう。

• node-solid-serverにハイブリッドルールを設定して、変更が仕様から逸脱している場合は、より長いレビュー時間が必要であると言うことができます。 仕様から逸脱した仕様をコードに実装する場合も、プロセスを用意することが重要です。

• ワークフローと手順は文書化されていません。

• エンジニアは、非エンジニアよりもパイプラインを信頼しています。 多分私たちはこれを信頼しています。 多分ポイントがあります。 開発者文化の人口統計、おそらくそれは私たちがそれが本来あるべき姿であると私たちが考えるからです。
• 重要な決定は、実際には技術を超えた大きな影響がある場合、技術的なものとして偽装されます。
• コードは社会に多大な影響を与える可能性があるため、その影響を理解し、人々が参加できるようにすることが非常に重要です。
• 自然言語–仕様では、どのような場合でも更新を使用できます。 そうすることで、物事を説明するためのより良い方法があります。 技術的要素を非技術的要素として書き直すことまでは行きません。 仕様の読みやすさを改善して、それが正しいことを確認する機会があります。 テクニカルが削除されると言って多くの反発を受けるでしょう。
  
  
  
  • 私たちは受け入れられるものを構築する必要があり、したがってすべての人が理解できる必要があります。
  
  

@TallTed前のコメントの議事録について何か考えはありますか？

前進する方法として、私は以下を提案します：

次のリポジトリに関連するプルリクエストと問題は、最低3日間開いている必要があります。
https://github.com/solid/solid-spec
https://github.com/solid/web-access-control-spec
https://github.com/solid/webid-oidc-spec
https://github.com/solid/community

他のすべてのリポジトリに関連するプルリクエストと問題はすぐに閉じることができ、仕様から逸脱しない限り、開いたままにしておく必要がある最小時間はありません。仕様から逸脱している場合は、最低3日間開いている必要があります。

異議はありますか？

私のために働きます。 リリースマネージャーの役​​割の説明に、残りのリポジトリで何をすべきかを説明するテキストを追加することもできます。

私もこの解決策が好きです：smile_cat：推論をどこかに書き留めて、人々がその背後にある私たちの考えを理解できるようにしましょう

@kjetilkはい、 https：//github.com/solid/community/pull/44にメモを追加します

@megoth okは、コミュニティリポジトリのreadmeに簡単な説明を含めます

https://github.com/solid/community/blob/master/README.md