Re: [Ietf-and-github] Alvaro Retana's Discuss on draft-ietf-git-using-github-05: (with DISCUSS and COMMENT)

On 12-Mar-20 07:53, Alvaro Retana via Datatracker wrote:
...

> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> This is a process DISCUSS.  I don't believe the status of this document as a
> BCP belonging to BCP 25 was discussed in the WG or with the IETF community.
> 
> The Charter for the git WG only explicitly mentions BCP 9:
> 
>    The documents produced by this group will not alter the Internet Standards
>    Process (BCP 9). They will describe how to work within it. Whether working
>    groups choose to use GitHub or the documented policies to support their work
>    will remain entirely at their discretion.
> 
> However, including this document as a part of BCP 25 (IETF Working Group
> Guidelines and Procedures) results in the interpretation that it represents
> consensus on how WGs should proceed -- and not that the decision "to use GitHub
> or the documented policies...[is]...entirely at their discretion."

Would a sentence to that effect in the Abstract and Introduction help? 

> My reading of the mailing list is that the current RFC Editor note (in which
> appending the document to BCP 25 is requested) was added only after the topic
> was brought up in the Genart LC review.  [Did I miss the discussion?]

Speaking as the Gen-ART reviewer, you're correct (and I regret not having
noticed this point earlier so that I could have brought it up in the WG).

> IOW, both (1) the process of reaching the conclusion that this document belongs
> in BCP 25, and (2) the concept that this document would be part of BCP 25, are
> the subject of my DISCUSS.    I would like for the IESG to discuss this topic.

Have things changed? In the old days this question (which BCP number?) was typically
left to the discretion of the RFC Editor, possibly with a bit of discussion
with the AD. I certainly don't object to community discussion, of course (and
we did do that in the case of BCP 101 recently).

   Brian

> Not expecting this document to be part of BCP 25, or having an explicit
> discussion with the community about it, would lead me to clear my DISCUSS.
> 
> ====
> [Non blocking comment.  I'm including it here because it is related to the
> status of the document.]
> 
> This document would be very good Informational document.
> 
> I am not a regular GitHub user (and none of the WGs I'm responsible for use it
> as part of their process), but I have no reason to doubt that the text
> represents what is believed to be the best way to use GitHub within the IETF
> process.  However, the designation as a BCP can create confusion.  [Again, this
> is a non-blocking comment.]
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> (0) I share Warren's concerns.
> 
> (1) The datatracker should list draft-thomson-git-using-github as being
> replaced by this document.
> 
> (2) It would be nice to have a short terminology section; I assume many people
> reading this document will not already be GitHub-savy, so push, pull, commits,
> may not be familiar to them.  Alternatively, an Informational pointer to a
> tutorial would also be ok.
> 
> (3) Personally, I don't have an issue with the use of GitHub, but some of the
> statements in the Introduction sound like marketing blurbs, for example:
> 
> - "Use of this service has been found to reduce the time that Working Groups
>    need to produce documents and to improve the quality of the final result."
> 
> - "...encourage contributions from a larger set of contributors."
> 
> - "Using GitHub can also broaden the community of contributors for a
>    specification."
> 
> (4) [nit] s/This is problematic for contributors who do not track discussion
> closely./This is problematic for contributors who do not track discussions
> closely.
> 
> (5) [major]  §5.3: "Working Group chairs SHOULD confirm that the Working Group
> has consensus to adopt any process."  When would the chairs not confirm
> consensus to adopt a process?  IOW, why is this not a MUST?
> 
> Note that §3 says this:
> 
>    Working Group Chairs are responsible for determining how to best
>    accomplish the charter objectives in an open and transparent fashion.
>    The Working Group Chairs are responsible for determining if there is
>    interest in using GitHub and making a consensus call to determine if
>    the proposed policy and use is acceptable.
> 
> Even though this text doesn't use rfc2119 keywords, my impression of the intent
> is that it is required for the chairs to make the consensus call.  IOW, I think
> that this text and the one above (from §5.3) are in conflict.
> 
> (6) §5.3.2:
> 
>    Gaining Working Group consensus about the resolution of issues can be
>    done in the abstract, with editors being permitted to capture the
>    outcome of discussions as they see fit.
> 
> This sentence doesn't sound right to me: "consensus...can be done in the
> abstract, with editors being permitted to capture the outcome...as they see
> fit".  That last part doesn't sound right: Chairs call consensus.  Maybe I'm
> misinterpreting...
> 
> (7) [major]. Why is draft-ietf-git-github-wg-configuration listed as a
> Normative Reference?  I don't think that dependency is needed.
> 
> 
> 
> _______________________________________________
> Ietf-and-github mailing list
> Ietf-and-github@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-and-github
> 