ついにRFCがGithubを本格的に使い始めた

Unknown Protocolでは過去に何度かRFC関連のことを書いていて、その伝統的なフォーマットにも一種の愛着を感じていたが、ここ1〜2年は大きな転換期なのかもしれない。

RFC8875は、その名も「Working Group GitHub Administration」ということでIETFのWGでのGithubの使い方に関するRFCだ。EditorはCiscoのAlissa Cooperと ICANNのPaul Hoffman。

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.

まず、RFCだからといってStandard Trackというわけではない。このドキュメントはIETFのconsensus(総意)を表すproductだという。

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.

IETF Datatrackerはdraftとして立ち上がってからRFCになるまでを追跡できるが、ここで既にarea directorがGithub organizationの作成を要求できるようになっている。

1. Create a GitHub organization for the working group.
2. Name the organization in the format 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.
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.

具体的には、こんな感じの手順で作られるのだが、このRFC8875自体がGithub上にorganizationを作ってやったかどうかはわからない。将来的にはDatatrackerに電子メールアドレスだけでなくGithubのアカウントも併記されるようになるのだろうか。

次に「Working Group GitHub Usage Guidance」というRFCも公開されている。こちらはMozillaのMartin ThomsonとAT&TのBarbara StarkがEditor。

Contributions to documents come in many forms. GitHub provides a range of options in addition to email. Input on GitHub can take the form of new issues and pull requests, comments on issues and pull requests, and comments on commits.

Githubをどう使うのか気になっていたが、issueやpull request、commitのコメントなどもインプットとして扱うようだ。

Editors have write access to repositories, which also allows them to close issues. The user that opens an issue is also able to close the issue. Chairs MUST provide guidance on who is permitted to close an issue and under what conditions. Restrictions on who can close an issue and under what circumstances are generally not advisable until a document has reached a certain degree of maturity.

Editorがリポジトリの権限を持ち、issueをクローズしたりできる。Chairはissueを誰にどういう条件でクローズさせるかのガイドラインを提供しなければならない。

このあとに、Pull Requestをどう運用するかなどのガイダンスも含まれているが、はたしてどれぐらい活用されるのだろう。

IETFに限らず、企業でもOSSの方法論として特にGithubのプルリク文化などを取り入れたいと考えているところは多いだろう。自分がプルリク文化がない組織にプルリクを取り入れる推進役となった場合、何かしらのガイダンスを作ることになると思うが、そのような場合にIETFはどうしたのかという点で参考になるのだろうか。

この記事が気に入ったら、サポートをしてみませんか?
気軽にクリエイターの支援と、記事のオススメができます!
7
すぐ使える新しい技術と、長い長い検討の末に辿り着いた古の技術が好きな自称エンジニアリングマネージャ。平日朝に更新することが多いです。

こちらでもピックアップされています

マガジン2
マガジン2
  • 1570本
コメントを投稿するには、 ログイン または 会員登録 をする必要があります。