Draft: draft-ietf-git-using-github

Commentary: I was tempted to remove the entire section on administrative policies , though left it as is . what do you think ? 
 Yeah , I figured it best to start small . Let me know if you need anything else before merging ! 
 Interesting that the circle  build ran on the merge , but not the PR . I did n't see any build failures reported before it merged , but I just got the email reporting a missed reference . Maybe there are some tweaks you need to apply over there as owner of the org . 
 Yeah , I 'll fix it . Thanks for letting me know ! 
 I was thinking of being a little more aggressive about removing some of the text , with matching PRs for the other work , but this works .
Paragraph (version A):
Organizations are a way of forming groups of contributors on GitHub.
Each Working Group SHOULD create a new organization for the working
group.
Paragraph (version A):
A working group organization SHOULD be named consistently so that it
can be found.  For instance, the name could be ietf-<wgname> or ietf-
<wgname>-wg.
Paragraph (version B):
Organizations are a way of forming groups of contributors on GitHub.
Each Working Group SHOULD create a new organization for the working
group.  A working group organization SHOULD be named consistently so
that it can be found.  For instance, the name could be ietf-<wgname>
or ietf-<wgname>-wg.
Paragraph (version A):
When Area Directors or Working Group Chairs change, teams MUST be
updated to reflect the new membership status.
Paragraph (version A):
When a Working Group is closed, the responsible Area Director is
responsible for removing existing members from teams in the
organization.  Repositories MUST be updated along to indicate that
they are no longer under development.
Paragraph (version A):
When an IETF Working Group is closed or when associated mailing lists
are closed, mail archives and datatracker information from that work
is backed up and accessible.  The same applies to GitHub
repositories.
Paragraph (version A):
Any repositories including issues and discussion SHOULD be backed up
on IETF resources.  It is desirable for those to be accessible via
the Working Group's datatracker page.  For example, this might be via
URLs listed in the More Info section on the Working Group Charter
page.
Paragraph (version A):
The IETF MAY decide to backup information associated with a Working
Group's organization periodically.  This decision can be made
differently per Working Group in consultation with the responsible
Area Director.
Paragraph (version B):
Details about creating organizations adhering to these guidelines can
be found in GIT-CONFIG.
Paragraph (version A):
One important policy is the IETF IPR policy (see RFC5378, RFC3979,
and RFC4879).  Part of this policy requires making contributors aware
of the policy.
Paragraph (version A):
The IETF Trust license file for open source repositories [5] MUST be
included prominently in any document repository.
Paragraph (version A):
Including this information in the CONTRIBUTING file is sufficient.
Paragraph (version A):
In addition to the boilerplate text there can be a benefit to
including pointers to other working group materials, the IETF
datatracker, specific drafts, or websites.  Adding such text is at
the discretion of the Working Group Chairs.
Paragraph (version A):
An alternative is to rely on periodic email summaries of activity,
such as those produced by a notification tool like github-notify-ml
[6].  This tool has been used effectively in several working groups,
though it requires server infrastructure.
Paragraph (version B):
An alternative is to rely on periodic email summaries of activity,
such as those produced by a notification tool like github-notify-ml
[5].  This tool has been used effectively in several working groups,
though it requires server infrastructure.