[要約] RFC 8875は、IETFのWorking Group GitHub Administrationに関する標準化文書です。このRFCの目的は、GitHubを使用してIETFのWorking Groupを管理するための手順とガイドラインを提供することです。
Internet Engineering Task Force (IETF) A. Cooper
Request for Comments: 8875 Cisco
Category: Informational P. Hoffman
ISSN: 2070-1721 ICANN
August 2020
Working Group GitHub Administration
ワーキンググループGithub政権
Abstract
概要
The use of GitHub in IETF working group processes is increasing. This document describes uses and conventions for working groups that are considering starting to use GitHub. It does not mandate any processes and does not require changes to the processes used by current and future working groups not using GitHub.
IETFワーキンググループプロセスにおけるGitHUBの使用は増加しています。このドキュメントでは、GitHubの使用を検討しているワーキンググループの使用と規則について説明します。どんなプロセスも義務付けられておらず、githubを使用していない現在および将来のワーキンググループで使用されるプロセスへの変更を必要としません。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準のトラック仕様ではありません。情報提供のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。IESGによって承認されたすべての文書がすべてのレベルのインターネット規格の候補者ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8875.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/frfc8875で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2020 IETFの信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Administrative Process and Conventions
2.1. Creation of GitHub Organizations
2.2. Migration of an Existing Organization
2.3. Personnel Changes
2.4. Working Group Closing
2.5. Creation of Document Repository
2.6. Listing Related Repositories
3. Working Group Process
3.1. Contributions
3.2. Backing Up and Archiving GitHub Content
4. Security Considerations
5. IANA Considerations
6. Informative References
Authors' Addresses
Many IETF working groups and participants make use of GitHub in different ways as part of their work on IETF documents. Some others are interested in having their working groups use GitHub to facilitate the development of working group documents, but they are unfamiliar with how to get started or unclear about which conventions to follow. Some other working groups use or plan to use other code-repository services such as GitLab and Bitbucket, which have different properties than GitHub.
多くのIETFワーキンググループと参加者は、IETF文書の作業の一部としてさまざまな方法でGitHubを利用しています。作業グループの文書の開発を容易にするために、作業グループを使用することに興味がある人もいますが、従来の規則について始める方法については、GitHubを使用しています。他のワーキンググループは、GitlabやBitbucketなどの他のコードリポジトリサービスを使用または計画しています。
This document specifies a set of administrative processes and conventions for IETF working groups to use if they choose as a working group to use GitHub to facilitate their work. The specifications in this document are not directed at working groups or individuals that are already using GitHub to do IETF work. Practices vary among existing working groups, and some of them are not consistent with the conventions proposed here: that is fine. The goal of the specifications in this document is not to require uniformity in current practice, but to help working groups get started using GitHub in a reviewed and validated way, if desired.
このドキュメントでは、WITHUBを使用してGitHubを使用して作業グループとして選択した場合に使用するIETFワーキンググループの管理プロセスと規則のセットを指定します。この文書の仕様は、githubを使用してIETF作業を行っているワーキンググループまたは個人には向けられていません。慣行は既存のワーキンググループによって異なります、そしてそれらのいくつかはここに提案されている規則と一致していません：それは問題ありません。この文書の仕様の目的は、現在の練習の均一性を要求することではなく、作業グループが必要に応じてレビューされ、検証された方法でGitHubを使い始めるのを助けることができます。
This section specifies an administrative process and conventions to support the creation and management of GitHub organizations for working groups and single-document repositories in a uniform way. The steps may be done manually by the IETF Secretariat, or they may be automated. See <https://github.com/richsalz/ietf-gh-scripts> and <https://github.com/martinthomson/i-d-template> for working examples of automation that is in use in some working groups.
このセクションでは、ワーキンググループと単一文書リポジトリのGitHub組織の作成と管理を一様な方法でサポートするための管理プロセスと規則を指定します。ステップは、IETF事務局によって手動で行われてもよく、または自動化されてもよい。一部のワーキンググループで使用されているオートメーションの動作例については、<https://github.com/scriphsalz/ietf-gh-scripts>と<https://github.com/martinthomson/i-d-template>を参照してください。
In this document the question of whether processes should be manual or automated is deliberately left unspecified, since these are implementation details that the IETF Secretariat and Tools Team will address.
この文書では、プロセスが手動であるか自動化されるべきかどうかという問題は、IETF事務局とツールチームが対処する実装の詳細です。
Most of the conventions below are drawn from [RFC8874].
以下の表記法のほとんどは[RFC8874]から描かれています。
This document specifies that there be a facility in the IETF Datatracker (<https://datatracker.ietf.org/>) interface to allow an area director (AD) or working group chair to request the creation of a GitHub organization for a particular working group. Ideally, this facility would appear both as part of the working group chartering UI and the working group page UI.
このドキュメントは、Area Director（AD）またはワーキンググループの椅子が特定のためにGitHub組織の作成を要求できるように、IETF DataTracker（<https://datatracker.ietf.org/>）インターフェイスに施設があることを指定しています。ワーキンググループ。理想的には、この機能は、ワーキンググループチャーターUIとワーキンググループのページUIの一部として表示されます。
When an area director or working group chair makes a request to create a GitHub organization, the following process would be initiated:
エリアディレクターまたはワーキンググループチェアがGitHub組織の作成を要求しているときは、次のプロセスが開始されます。
1. Create a GitHub organization for the working group.
1. ワーキンググループのためのGitHub組織を作成します。
2. Name the organization in the format ietf-wg-<wgname>...
2. 組織にIETF-WG- <WGNAME>の形式で名前を付けます。
3. Initialize the organization by designating the IETF Secretariat and the area directors in the working group's area as owners. If the responsible AD for the working group is from another area, that AD will be an owner as well.
3. ワーキンググループの地域のIETF事務局と地域取締役を所有者として指定することで、組織を初期化します。ワーキンググループの責任ある広告が別の地域からのものである場合、その広告も所有者になるでしょう。
4. Initialize the organization with a team that has administrator access. This team will consist of the working group chairs and working group secretary, if one exists.
4. 管理者アクセス権を持つチームを使用して組織を初期化します。このチームは、存在する場合、作業グループの椅子と作業グループの秘書で構成されます。
After the organization is created, the URL for the organization would be added to the working group's page in the Datatracker.
組織が作成された後、組織のURLがDataTrackerのワーキンググループのページに追加されます。
Steps 3 and 4 above imply that the GitHub identities of the organization owners and administrators are known. Recording GitHub identities in the Datatracker (see <https://trac.tools.ietf.org/tools/ietfdb/ticket/2548>) would facilitate this. The person requesting the organization would need to be notified if the GitHub identities of any of the people meant to be owners or administrators were not available.
上記のステップ3と4は、組織所有者と管理者のGithub IDが知られていることを意味します。DataTrackerのgithub識別情報の録音（<https://trac.tools.ietf.org/tools/ietfdb/ticket/2548>を参照）を促進します。所有者または管理者になることを意図した人のgithub IDが利用できなかった場合、組織に要求する人に通知する必要があります。
If a working group already has an organization, it would be useful to be able to make it have the same management as one would get by going through the steps in Section 2.1. That is, it would be good to be able to run Steps 3 and 4 from Section 2.1 so that the rest of the activities in this section, such as personnel changes, work the same way as for organizations that were created as specified herein.
ワーキンググループがすでに組織を持っている場合は、セクション2.1の手順を実行することで、同じ管理を行うことができるようにすることができると便利です。つまり、セクション2と4からステップ3と4を実行できるように、このセクションでのアクティビティの残りの部分は、人事の変更など、ここで指定されたように作成された組織と同じように機能します。
When there are personnel changes in the area or the working group, those changes would be reflected in the GitHub organization. There should be an ability in the Datatracker to specify that personnel changes have occurred.
地域や作業部会に人員の変更がある場合、それらの変更はGitHub組織に反映されます。DataTrackerには、人事変更が発生したことを指定することができます。
When a working group is closed, the team with administrative access would be removed, and the owner list would be returned to the Secretariat and current ADs at the time of closing. The organization summary and the repositories within the organization would be updated to indicate that they are no longer under development. Later, the owner list could become just the Secretariat, or it might include others chosen by the Secretariat or the IESG.
ワーキンググループが閉じられると、管理アクセスを含むチームが削除され、所有者リストは閉じる時点で事務局と現在の広告に返されます。組織内の組織の概要とリポジトリは、それらがもはや開発中ではないことを示すために更新されます。後で、所有者リストは事務局だけである可能性があるか、事務局やIESGによって選ばれた他の人が含まれるかもしれません。
There are many different scenarios and configurations where it might be useful to have automation or established administrative conventions for repositories within WG organizations, such as:
WG組織内のリポジトリのための自動化または確立された管理規則を持つことが有用である可能性があるさまざまなシナリオと構成がさまざまです。
* Creating a new repository for an individual draft (at the discretion of the WG chair);
* 個々のドラフトのための新しいリポジトリを作成する（WGの議長の裁量）。
* Creating a new repository for an already adopted working group draft;
* 既に採用されているワーキンググループドラフトのための新しいリポジトリを作成する。
* Migrating an existing document repository into the WG organization; and
* 既存の文書リポジトリをWG組織に移行する。そして
* Creating a new repository that contains multiple drafts.
* 複数のドラフトを含む新しいリポジトリを作成します。
As an incremental step, this document specifies that there be a facility in the Datatracker interface to allow an administrator of an ietf-wg-<wgname> organization to request the creation of a new repository within that organization for a single document. The document authors would be identified as collaborators. The repository name would be the draft name. Ideally, the repository would be configured with a skeleton draft file, default CONTRIBUTING, LICENSE, and README files, and continuous integration support, in the vein of <https://github.com/martinthomson/i-d-template>. Performing this step would automatically inform the IETF Secretariat that this repository should be backed up as described in Section 3.2.
増分ステップとして、このドキュメントは、IETF-WG-<WGNAME>組織の管理者が単一の文書のためにその組織内で新しいリポジトリの作成を要求できるようにするために、DataTrackerインタフェースに機能があることを指定します。ドキュメントの著者は共同資金社として識別されます。リポジトリ名はドラフト名になります。理想的には、リポジトリは、<https://github.com/martinthomson/i-template>の静脈内で、スケルトンドラフトファイル、デフォルトの貢献、ライセンス、およびREADMEファイル、および継続的な統合サポートを使用して構成されます。この手順を実行すると、このリポジトリをセクション3.2に示すようにバックアップする必要があることをIETF事務局に自動的に通知します。
The IETF Datatracker should allow users to add links to repositories (for GitHub and other repository services) on working group, document, and user pages. At the time of this writing, this feature was under development.
IETF DataTrackerは、ユーザーがワーキンググループ、ドキュメント、およびユーザーページのリポジトリへのリンク（GitHubおよびその他のリポジトリサービスの場合）を追加できるようにします。この書き込み時には、この機能は開発中です。
[RFC8874] contains discussion of the different possible ways that a working group can use GitHub and the large number of decisions associated with doing so. This section specifies a basic set of administrative policies for working groups to follow and the administrative support needed to carry out those policies.
[RFC8874]ワーキンググループがGitHubを使用できる可能なさまざまな方法やそのように関連する重要な数の決定を含みます。このセクションでは、従来の作業グループの管理ポリシーの基本的なセットとそのポリシーを実行するために必要な管理サポートを指定します。
At a minimum, every repository created in a working group organization needs to incorporate into its CONTRIBUTING file the boilerplate text at <https://trustee.ietf.org/license-for-open-source-repositories.html> from the IETF license file for open-source repositories. The CONTRIBUTING file can contain other information as well (see <https://github.com/ietf/repo-files/tree/master/ contributing-samples> for examples).
最低限、ワーキンググループ組織で作成されたすべてのリポジトリは、<https://trustee.ietf.org/license-or-open-source-repositories.html>のボイラープレートテキストをその貢献ファイルに組み込む必要があります。オープンソースリポジトリ用のファイル。貢献ファイルにも他の情報も含めることができます（<https：//github.com/ietf/repo-files/tree/master/ contribution-samples>を参照）。
It would be useful if the user data in the Datatracker could list (at a minimum) the GitHub account of the user so that their contributions could be tracked more easily.
DataTracker内のユーザーデータがユーザーのGitHubアカウントを（最小）している場合は便利です。
Some working groups choose to have more than one draft in a repository, particularly for drafts that are tightly linked with significant cross-references. In such a case, the README for the repository needs to say so clearly, so that a participant understands that changes might be made to multiple drafts at once.
一部のワーキンググループは、特に有意な相互参照としっかりとリンクされているドラフトで、リポジトリに複数のドラフトを持つことを選択します。そのような場合、リポジトリのREADMEはそれほど明確に言う必要があるため、参加者は一度に複数のドラフトに変更される可能性があることを理解しています。
IETF working group mailing lists are automatically backed up by the IETF Secretariat, and the archives are publicly available. All official interactions in a WG must be archived.
IETFワーキンググループのメーリングリストは、IETF事務局によって自動的にバックアップされ、アーカイブは公に利用可能です。WG内のすべての公式インタラクションをアーカイブする必要があります。
Working group GitHub content also needs to be backed up and publicly archived. This document specifies using the Git protocol [git-protocol] itself for both of these tasks.
ワーキンググループのGitHubコンテンツもバックアップして公にアーカイブされる必要があります。このドキュメントは、これらのタスクの両方についてGITプロトコル[git-protocol]自体を使用して指定します。
Every IETF working group repository on GitHub will have a mirror repository of the same name on a server maintained by the IETF Secretariat. Every hour, a service will use the "git fetch" command on every GitHub repository that is being tracked. The mirror repository will allow anyone to read the repository.
GitHub上のすべてのIETFワーキンググループリポジトリは、IETF事務局によって維持されているサーバー上の同じ名前のミラーリポジトリを持ちます。毎時、サービスは追跡されているすべてのGitHubリポジトリの "git fetch"コマンドを使用します。ミラーリポジトリは、誰でもリポジトリを読むことができます。
Note that this system will not back up GitHub issues or pull requests. These should be backed up as well; the GitHub API allows for this. The IETF Secretariat should back up those at the same time as it is backing up the GitHub repositories.
このシステムはGitHubの問題をバックアップしたり、要求を引き上げることはありません。これらはバックアップされるべきです。GitHub APIはこれを可能にします。IETF事務局は、Githubリポジトリをバックアップしているのと同時にそれらをバックアップする必要があります。
The steps in Section 2.5 inform the IETF Secretariat which repositories should be backed up. Working group chairs and area directors should also be able to request that the IETF Secretariat back up additional repositories that are related to IETF working groups.
セクション2.5の手順では、リポジトリをバックアップする必要があるIETF事務局に通知します。ワーキンググループのチェアとエリアディレクターは、IETF事務局がIETFワーキンググループに関連する追加のリポジトリをバックアップするように要求することもできます。
An attacker who can change the contents of Internet-Drafts, particularly late in a working group's process, can possibly cause unnoticed changes in protocols that are eventually adopted.
インターネットドラフトの内容を変更できる攻撃者、特にワーキンググループのプロセスが遅れて、最終的に採用されているプロトコルの気付かされない変更を引き起こす可能性があります。
There is a risk of data loss due to centralization of data in one service. This is recognized and mitigated by the plan described in Section 3.2.
1つのサービス内のデータの集中化によるデータ損失のリスクがあります。これはセクション3.2で説明されている計画によって認識され軽減されます。
This document has no IANA actions.
この文書にはIANAの行動がありません。
[git-protocol] Chacon, S. and B. Straub, "Git on the Server - The Protocols", in Pro Git, 2014, <https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols#The-Git-Protocol>.
[git-protocol] Chacon、S.およびB. Straub、Pro Git、2014、<https：//git-scm.com/book/en/v2/git-onの "議論"-the-server-the-protocols＃-git-protocol>。
[RFC8874] Thomson, M. and B. Stark, "Working Group GitHub Usage Guidance", RFC 8874, DOI 10.17487/RFC8874, August 2020, <https://www.rfc-editor.org/info/rfc8874>.
[RFC8874] Thomson、M.およびB.Stark、 "Working Group Github使用ガイダンス"、RFC 8874、DOI 10.17487 / RFC8874、<https：//www.rfc-editor.org/info/rfc8874>。
Authors' Addresses
著者の住所
Alissa Cooper Cisco
Alissa Cooper Cisco.
Email: alcoop@cisco.com
Paul Hoffman ICANN
Paul Hoffman icann.
Email: paul.hoffman@icann.org