InnerSourceCommons / InnerSourceCommons/InnerSourcePatterns

Pattern idea: "Contribution negotiation"

オープン
#410 コメント 5 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

:bulb: Early Idea
主要言語
HTML
スター
853
フォーク
206
平均マージ
1日 23時間
マージ済み PR(30日)
2

説明

In reading through some of the patterns in the initial phase in the "reluctance to accept contributions" I came across a cross reference to a pattern idea that I found interesting:

"Contribution negotiation"

The solutions discussed in "Reluctance to Accept Contributions" include the "30 day warranty" pattern, but also clear process and guidelines around how to submit contributions. The pattern does not talk about expectation management around which types of contributions would be interesting to the host project. It also does not discuss any negotiations or communication that may occur before the changes are made and submitted. In our contributor training (in the Learning Path) we discuss some of that in more detail: Contributions start not with submitting the patch set. Rather contributors should reach out to the host team before making modifications to seek guidance on whether the changes make any sense in terms of roadmap, general architecture and the like. A side effect could be that the host team offers mentoring time thus reducing the time to implement a modification. Such communication would be particularly helpful for larger changes. The entire communication should happen in project channels that are company-wide accessible, archived and linkeable so they can be referenced in the future.

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

調査の方向性

まず、リンクされている Reluctance to Accept Contributions パターンと 30-day warranty パターンを読み、その後、issue で参照されている contributor 向けトレーニング資料を確認してください。完成した contribution には、より大きな変更を実装する前に、パターンのスコープについて合意し、期待値の設定、コミュニケーション、交渉に関するガイダンスを文書化することが必要です。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
markdown
領域
documentation
issue の種類
ドキュメント
難易度
5/5
見積もり時間
1週間以上
活発さ
停滞
明瞭さ
説明が足りない
初心者へのやさしさ
25/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。