NuGet のガバナンスNuGet governance

この文書は、オックスフォード大学のヴェノベレント ディクテーター ガバナンス モデルに基づいています。This document is based upon the Benevolent Dictator Governance Model by the University of Oxford. これは、クリエイティブ コモンズの表示 - 継承 2.0 イングランド & ウェールズ ライセンスにライセンスされています。It is licensed under a Creative Commons Attribution-ShareAlike 2.0 UK: England & Wales License.

NuGet プロジェクトのリーダーは、ヴェノベレント ディクテーターであり、管理はそのコミュニティが行います。The NuGet project is led by a Benevolent Dictator and managed by the community. つまり、プロジェクトの日々のメンテナンスはコミュニティが積極的に行いますが、一般の戦略線はヴェノベレント ディクテーターによって描かれます。That is, the community actively contributes to the day-to-day maintenance of the project, but the general strategic line is drawn by the benevolent dictator. 意見の相違があった場合、ヴェノベレント ディクテーターが最終決定をします。In case of disagreement, the benevolent dictator has the last word.

ヴェノベレント ディクテーターの仕事は、コミュニティ内の問題を解決し、プロジェクトを協調的に進めることです。It is the benevolent dictator’s job to resolve disputes within the community and to ensure that the project is able to progress in a coordinated way. それに対して、コミュニティは、積極的に関わり貢献することによって、ヴェノベレント ディクテーターを意思決定に導きます。In turn, it's the community’s job to guide the decisions of the benevolent dictator through active engagement and contribution.

役割と責任Roles and responsibilities

ここでは、ヴェノベレント ディクテーター、コミッター、共同作成者、およびユーザーの 4 つの役割について説明します。There are four roles described here: Benevolent Dictator, Committers, Contributors, and Users.

ヴェノベレント ディクテーターBenevolent dictator

ヴェノベレント ディクテーターまたはプロジェクト リーダーには、NuGet のコア チームが自己推薦されます。The NuGet core team is self-appointed as Benevolent Dictator or project lead. ただし、コミュニティは常にフォークすることができるため、このチームはコミュニティに完全な釈明義務を負っています。However, because the community always has the ability to fork, the team is fully answerable to the community. プロジェクト リーダーは、プロジェクトが長期にわたって継続されることを保証しながら、コミュニティ全体を理解し、相対するニーズを可能な限り満たすように努力することが期待されています。The project lead is expected to understand the community as a whole and strive to satisfy as many conflicting needs as possible, while ensuring that the project survives in the long term.

ヴェノベレント ディクテーターの役割は、多くの意味で、独裁的に物事を進めるというよりは、交渉で進めます。In many ways, the role of the benevolent dictator is less about dictatorship and more about diplomacy. プロジェクトが拡大するときに、正しい人々がそれから影響を受け、プロジェクト リーダーのビジョンの下にコミュニティがまとまるようにすることが重要です。The key is to ensure that, as the project expands, the right people are given influence over it and the community rallies behind the vision of the project lead. このときのリーダーの責務は、コミッター (以下参照) がプロジェクトで正しい判断を下すことができるようにすることです。The lead’s job is then to ensure that the committers (see below) make the right decisions on behalf of the project. 一般的には、コミッターがプロジェクトの戦略と同調している限り、プロジェクト リーダーは彼らの希望通りに進めさせます。Generally speaking, as long as the committers are aligned with the project’s strategy, the project lead will allow them to proceed as they desire.

.NET Foundation スタッフでは、これ以外に、プロジェクト リーダーは、ドメインの登録や技術的なサービス (コード署名など) を含むビジネス処理における Nuget の主な連絡窓口または最初の接点であると考えています。Additionally, .NET Foundation staff consider the project lead the primary or first point of contact for NuGet for purposes of business operations including domain registrations, and technical services (e.g. code-signing).

コミッターCommitters

コミッターとは、NuGet に継続的に貴重な貢献を行っている共同作成者であり、ヴェノベレント ディクテーターによって任命されます。Committers are contributors who have made sustained valuable contributions to NuGet and are appointed by the Benevolent Dictator. 任命されると、コミッターはリポジトリに直接コードを書き込むこと、および他の作成者のコントリビューションを評価することの両方が求められます。Once appointed, committers are relied upon to both write code directly to the repository and screen the contributions of others. コミッターはしばしば開発者ですが、他の方法でも貢献します。Committers are often developers but can contribute in other ways.

通常、コミッターは、コミュニティおよびプロジェクト リーダーからの尊敬を勝ち取るある水準の専門知識と知力をプロジェクトの特定の局面に提供します。Typically, a committer focuses on a specific aspect of the project, and brings a level of expertise and understanding that earns them the respect of the community and the project lead. コミッターの役割は正式なものではなく、プロジェクト リーダーと仮定されるコミュニティに対する影響力があるメンバーが、単に助言やサポートを求めるポジションです。The role of committer is not an official one, it's simply a position that influential members of the community assume as the project lead looks to them for guidance and support.

コミッターは、NuGet の全体的な方向に関しては権限がありません。Committers have no authority where the overall direction of NuGet is concerned. ただし、プロジェクト リーダーからは話を聞いてもらえます。However, they do have the ear of the project lead. コミュニティで求められていることや包括的な目標をリーダーに認識させ、プロジェクトに対する適切な寄稿の開発を支援したり、それを引き出すことがコミッターの仕事です。It is a committer’s job to ensure that the lead is aware of the community’s needs and collective objectives, and to help develop or elicit appropriate contributions to the project. しばしば、コミッターはコミッターの特定の担当専門領域を監督することを非公式に任されており、ソース コードの特定の領域を直接変更する権限が付与されています。Often, committers are given informal control over their specific areas of responsibility, and are assigned rights to directly modify certain areas of the source code. つまり、コミッターには意思決定を行う明確な権限はありませんが、彼らが取る行動は、リーダーによる決定としばしば同じです。That is, although committers do not have explicit decision-making authority, they will often find that their actions are synonymous with the decisions made by the lead.

共同作成者Contributors

共同作成者とは、NuGet に更新プログラムを提出するコミュニティ メンバーです。Contributors are community members who submit patches to NuGet. これらの更新プログラムは、1 回限りのものと、経時的に発生するものとがあります。These patches may be a one-time occurrence or occur over time. 最初は小規模な更新プログラムを提出し、共同作成者、コミッターおよびプロジェクト リーダーが共同作成者の更新プログラムの品質に問題がないと判断した場合に、それを徐々に大きくしていくことが共同作成者には期待されています。Expectations are that contributors submit patches that are small at first and grow larger when the contributor, committers, and the project lead have built confidence in the quality of a contributor's patches. 共同作成者は、関連する製品のリリース ノートで確認できます。Contributors are recognized in the associated product release notes document.

最初の更新プログラムがリポジトリに配置される前に、共同作成者は、.NET Foundation の貢献者ライセンス同意書または譲渡契約書に署名する必要があります。Before a contributor’s first patch is put into the repository, they must sign a Contributor License Agreement or an assignment agreement to the .NET Foundation. 更新プログラムの提出および議論は可能ですが、実際に適切な書類なしにそれをリポジトリにコミットすることはできません。The patch can be submitted and discussed but it can’t actually be committed to the repository without the appropriate paperwork in place. 貢献者ライセンス同意書を取得するには、contributions@nuget.org にリクエストを送信してください。To obtain a contributor license agreement, please send a request in email to contributions@nuget.org.

共同作成者になるには、次のいずれかのリポジトリに pull request を送信してください。To become a contributor, submit a pull request to one of the following repositories:

pull request を送信する詳細な手順は、リポジトリによって異なります。The detailed process for submitting a pull request varies by repository:

ユーザーUsers

ユーザーとは、パッケージの使用者または作成者として NuGet にニーズがあるコミュニティ メンバーです。Users are community members who have a need for and use NuGet, as package consumers and/or authors. ユーザーは、コミュニティの最重要メンバーです。彼らがいないと、プロジェクトには目的がありません。Users are the most important members of the community: without them, the project would have no purpose. ユーザーは誰でもなることができ、特定の要件はありません。Anyone can be a user; there are no specific requirements.

ユーザーは可能な限り、NuGet の有効期間およびコミュニティに参加することが推奨されます。Users should be encouraged to participate in the life of NuGet and the community as much as possible. プロジェクト チームは、ユーザーの貢献により、ユーザーのニーズを満たしていることを確認できます。User contributions enable the project team to ensure that they are satisfying the needs of those users. ユーザーの一般的なアクティビティの一部を次に示します。Common user activities include but are not limited to the following:

  • プロジェクトの使用に賛同するAdvocating for use of the project
  • 新しいユーザーの視点からプロジェクトの長所と短所を開発者に伝えるInforming developers of project strengths and weaknesses from a new user’s perspective
  • 精神的な支えとなる (ありがとうは大きな効果をもたらす)Providing moral support (a thank you goes a long way)
  • 文書やチュートリアルを記述するWriting documentation and tutorials
  • バグ レポートや機能要求を提出するFiling bug reports and feature requests
  • バグ バッシュなどコミュニティのイベントに参加するParticipating in community events, such as bug bashes
  • インターネット上での掲示板またはフォーラムに参加するParticipating on discussion boards or forums

プロジェクトとそのコミュニティへの関与を続けるユーザーは、しばしばそれにますます関わっていくことでしょう。Users who continue to engage with the project and its community will often find themselves becoming more and more involved. そのようなユーザーは、やがて前述の共同作成者になります。Such users may then go on to become contributors, as described above.

特別な状況下でのパッケージの継承Package succession under special circumstances

NuGet のアカウント所有者が、不幸にも資格を取り消されたり、亡くなってしまった場合、そのアカウントが 1 人のユーザーに所有され、そのパッケージが OSI によって承認されたライセンスによって公開されるように、コミュニティと連携しパッケージに適切なオーナーが追加されるようにします。In the unfortunate situation where a NuGet account holder is incapacitated or deceased, we’ll work with the community to add appropriate owner/s to the package where the said account has sole ownership and the package is published under an OSI approved license. 所有権を要求する場合、次の文書を送信する必要があります。To request ownership you must send us the following documents:

  1. 政府発行の写真付き身分証明書の複写。A photocopy of your government-issued photo ID.
  2. 以前のアカウント保有者の状態を示す以下の文書のいずれか。One of the following documents proving the previous account holder’s status:
    • 前のアカウント保有者が死亡した場合、政府発行の公的な死亡証明書。An official, government-issued death certificate if the previous account holder is deceased, or,
    • 資格を剥奪されたアカウント保有者の管理を担当する医療専門家によって署名された証明書などの認定文書。A certified document such as a certificate signed by a medical professional in charge of the care of an incapacitated account holder.
  3. 所有権があることを示す次のいずれかの文書。One of the following documents proving your right to ownership:
    • アカウント保有者の生存配偶者であることを示す結婚証明書。Marriage certificate showing that you are the surviving spouse of the account holder,
    • 署名された委任状。Signed power of attorney,
    • ユーザーを遺言執行者または信託受益者とする遺言または信託証書。Copy of a will or trust document naming you as executor or beneficiary,
    • ユーザーがその親である場合、アカウント保有者の出生証明書。Birth certificate for the account holder, if you are their parent, or,
    • ユーザーがアカウント保有者の法定後見人の場合、後見人立証書類。Guardianship paperwork if you are a legal guardian of the account holder.

このポリシーを行使する必要がある場合、身分証明書とパッケージのバージョンを support@nuget.org に電子メールで送信してください。If you find yourself in need of invoking this policy, please send us an email at support@nuget.org with the ID and version of the package.

[透明度]Transparency

オープン ソースのプロジェクトのガバナンスの成功には、コミュニティ内で信頼を構築することが不可欠です。Building community trust in the governance of an open-source project is vital to its success. そのために、意志決定を行う場合、透明性を確保しながら、オープンに行う必要があります。To that end, decision making must be done in a transparent, open fashion. プロジェクトの方向に関する議論は、公開で行う必要があります。Discussion about the project’s direction must be done publicly. コミュニティは、ヴェノベレント ディクテーターの意思決定に不意を突かれないようにする必要があります。The community should never be caught off-guard by a decision by the Benevolent Dictator. また、コミュニティ メンバーが意思決定とその内容の全過程を理解できるよう、プロジェクトの意思決定に関する議論を保存記録する必要があります。Additionally, discussion about project decisions must be archived so that community members can understand the entire history of a decision and its context.