Subject: [Ietf-and-github] Spencer Dawkins' Yes on charter-ietf-git-00-00: (with COMMENT)

From: Spencer Dawkins <[email-masked]>
Date: Tue, 15 Jan 2019 10:07:00 -0800

Spencer Dawkins has entered the following ballot position for
charter-ietf-git-00-00: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-git/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(I had some comments during Internal Review that I haven't seen replies to, but
this is close enough to send out the way it is)

Many IETF working groups use external code repository services, primarily
GitHub, in managing their work. Individual working groups, while continuing
to operate within IETF guidelines for working group activity, have developed
their own policies and practices for how they use these services. These
policies and practices cover aspects such as: managing discussion between
working group mailing lists and GitHub issues and pull requests; how text
contributions are expected to be made; labeling and naming conventions;
maintaining readable draft snapshots; using tooling and automation; and
others.

<Spencer> I don't know whether best practices for Note Well awareness are
implicitly covered here, but I remember that's often a subject that comes up
when a working group starts to use Github. The examples given aren't
exhaustive, so perhaps they're sufficient, but it comes up so often it might be
worth mentioning explicitly. </Spencer>

The GitHub Integration and Tooling (GIT) working group will select a set of
such practices and document policies that support those practices. The
policies will each detail how work is conducted by working groups that opt to
follow the work practice. The goal is to provide both process and tooling
support for working groups that choose to adopt the documented practices.

<Spencer> I don't actually know how stable the way Github works has been in
recent years, or how stable it's expected to be. Is the goal for this working
group one-and-done, or are we talking about an ongoing process as the way
Github works, and the way IETF working groups work, evolves?  </Spencer>

The documents will not alter the Internet Standards Process (BCP 9), they
will describe how to work within it. Whether working groups choose to use
GitHub to support their work will remain entirely at their discretion.

The working group may also discuss tooling requirements in support of GitHub
use. Decisions about implementing specific tooling needs will be undertaken
in consultation with the IETF Tools Team and other interested contributors.

<Spencer> It should surprise no one that I don't actually know who makes those
decisions, which hasn't mattered for my time on the IESG up to this point, but
I thought I should ask now if this is the way people expect the chartered
working group to interact with the IETF Tools Team. One might read this as
saying the working group plus the IETF Tools Team (and other interested
contributors) are the decision makers. If that's correct, awesome.  </Spencer>

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 23 Jan 2019 13:26:42 -0500

Hi Spencer,

> On Jan 15, 2019, at 1:07 PM, Spencer Dawkins <[email-masked]> wrote:
> 

How about if we add “informing participants about IETF policies” to the semi-colon-delimited list? 

> Github works, and the way IETF working groups work, evolves?  </Spencer>

I think the goal of this proposed group is to document policies in a generic enough way that they apply to the basic components of what has been the typical GitHub workflow (orgs, repos, issues, PRs, tags, etc.) for the last few years and likely will continue to be for the next few. But if some significant change occurs someone could suggest a new milestone within the charter or suggest a re-charter after the first envisioned deliverables are done. 

> contributors) are the decision makers. If that's correct, awesome.  </Spencer>

Good catch. That should probably say “Decisions about implementing specific tooling needs will be undertaken by the IETF Tools Team in consultation with working group participants and other interested contributors.” The point is that the tools team still manages the prioritization of the tools work.

Alissa

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 23 Jan 2019 21:34:25 -0600

Hi, Alissa,

> semi-colon-delimited list?

That works (if you woke up any IETF Github person out of a sound sleep and
said "what policies do we need to inform participants about?", they'd say
"Note Well", but there may be other policies, now or in the future, so
generic is good).

Thanks for that one.

> I think the goal of this proposed group is to document policies in a
> generic enough way that they apply to the basic components of what has been
> the typical GitHub workflow (orgs, repos, issues, PRs, tags, etc.) for the
> last few years and likely will continue to be for the next few. But if some
> significant change occurs someone could suggest a new milestone within the
> charter or suggest a re-charter after the first envisioned deliverables are
> done.
>

That's probably what any reasonable IESG would do in the future, so no need
for a text change that I can see.

> Good catch.

(I'm glad! I wonder what percentage of my ballot positions have started out
"I don't actually know how this works, but" - 80 percent? If this Nomcom
didn't give you a designated clueless AD as my replacement, you folks might
add that to the generic position descriptions for next year :-)

> That should probably say “Decisions about implementing specific tooling
> needs will be undertaken by the IETF Tools Team in consultation with
> working group participants and other interested contributors.” The point is
> that the tools team still manages the prioritization of the tools work.

Thanks for the help with that. Your answer is the way I thought it worked,
but wanted to ask before the charter was approved.

Spencer