Subject: [Cellar] Matroksa/EBML and GitHub

From: Tessa Fallon <[email-masked]>
Date: Tue, 29 Dec 2015 11:15:38 -0500

Hi all,

I've been approached by several people about the idea of moving this work
as it relates to the IETF specifications to a GitHub repository to
facilitate collaboration.  If there is a group consensus that this would be
productive, I'm happy to set it up.  I would also like to ask if there
might be any volunteers willing to administer the account on a day to day
basis.  We would need to agree on procedures for approving/evaluating pull
requests and pushing changes before setting up the repository.

Best,

Tessa

---

From: Dave Rice <[email-masked]>
Date: Tue, 29 Dec 2015 11:25:47 -0500

+1, especially for the components not already in GitHub.

> On Dec 29, 2015, at 11:15 AM, Tessa Fallon <[email-masked]> wrote:
> 
> Hi all,
> 
> I've been approached by several people about the idea of moving this work as it relates to the IETF specifications to a GitHub repository to facilitate collaboration.  If there is a group consensus that this would be productive, I'm happy to set it up.  I would also like to ask if there might be any volunteers willing to administer the account on a day to day basis.  We would need to agree on procedures for approving/evaluating pull requests and pushing changes before setting up the repository.
> 
> Best,
> 
> Tessa
> _______________________________________________
> Cellar mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cellar

---

From: Ashley Blewer <[email-masked]>
Date: Tue, 29 Dec 2015 11:29:00 -0500

+1 as well. I'm also willing to act as one of the administrators for this
site.

I'm eager to show off what moving documentation to Github Pages would look
like and start conversations around that!

Ashley

On Tue, Dec 29, 2015 at 11:25 AM, Dave Rice <[email-masked]> wrote:

> > I've been approached by several people about the idea of moving this
> work as it relates to the IETF specifications to a GitHub repository to

---

From: Moritz Bunkus <[email-masked]>
Date: Tue, 29 Dec 2015 17:44:15 +0100

Hey,

I'm all for it, and I'm also volunteering for the admin job. I'm already
doing that for the current EBML RFC work anyway.

As for the account: there is the Matroska organization account on
Github[1] where the current work on creating the EBML RFC is taking
place. Currently Steve Lhomme and myself have admin privileges for that
organization. As your subject only talks about Matroska and EBML I'd
consider the Matroska-Org account to be a possible if not the most
appropriate place to host those sub-projects, and I'd welcome making
more people admins and granting push privileges to others.

If, however, your scope is somewhat wider and encompasses e.g. FFVW1
then I'm not so sure about that.

You've explicitly mentioned creating a new account. What are your
thoughts regarding the existing Matroska-Org account – anything specific
against using it? Thanks.

[1] https://github.com/Matroska-Org

Kind regards,
mosu

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Tue, 29 Dec 2015 09:02:51 -0800

Tessa Fallon wrote:
> to day basis.  We would need to agree on procedures for
> approving/evaluating pull requests and pushing changes before setting up
> the repository.

Since a number of people here may be new to the IETF... the normal 
procedure for individual drafts is "author discretion". I.e., this 
should be managed directly by the document editors. However, once a 
draft is formally adopted by the working group it is meant to reflect 
working group consensus, as per RFC 7221. In practice that looks a lot 
like "author discretion", though there are important differences (see 
Section 1.2, Working Group Authority and Consensus). I.e., the working 
group places a lot of trust in the document editors. Currently we have 
no drafts that have been formally adopted as working group drafts.

It is possible to grant commit access on Github more broadly than to 
just the official document editors, but then it becomes the editors' 
responsibility to ensure the document accurately reflects WG consensus 
before publishing a new version at the IETF. I think we can leave that 
decision up to the individual editors, once we have some. I.e., we can 
let the document editors choose whom they wish to trust.

With Github there is a danger that substantive discussion moves away 
from the mailing list (where it is subject to the IETF Note Well and 
other rules), and onto individual pull requests and Github issues, which 
can make the presence of working group consensus less clear. I would 
encourage people to keep substantive discussion on the mailing list. If 
you see discussions that are more than merely administrative, please 
send a message to the list about them.

---

From: Dave Rice <[email-masked]>
Date: Tue, 29 Dec 2015 12:27:59 -0500

Hi,

> On Dec 29, 2015, at 12:02 PM, Timothy B. Terriberry <[email-masked]> wrote:
> 
> Tessa Fallon wrote:
> Since a number of people here may be new to the IETF... the normal procedure for individual drafts is "author discretion". I.e., this should be managed directly by the document editors. However, once a draft is formally adopted by the working group it is meant to reflect working group consensus, as per RFC 7221. In practice that looks a lot like "author discretion", though there are important differences (see Section 1.2, Working Group Authority and Consensus). I.e., the working group places a lot of trust in the document editors. Currently we have no drafts that have been formally adopted as working group drafts.

We have many works in progress for EBML, Matroska, FFV1 and FLAC.  These are currently in GitHub repos, Drupal, or websites. At what point should they become 'working group drafts'? Is there a particular threshold in the work on these underlying documents to cross in order to be a working group draft?

> It is possible to grant commit access on Github more broadly than to just the official document editors, but then it becomes the editors' responsibility to ensure the document accurately reflects WG consensus before publishing a new version at the IETF. I think we can leave that decision up to the individual editors, once we have some. I.e., we can let the document editors choose whom they wish to trust.
> 
> With Github there is a danger that substantive discussion moves away from the mailing list (where it is subject to the IETF Note Well and other rules), and onto individual pull requests and Github issues, which can make the presence of working group consensus less clear.

I think this has been the case although I've made some reports back to the list to summarize changes. However I can switch to a FFmpeg style of patching and send patches to this list for review (rather than github pull requests) and the document editor can manage their application.

> I would encourage people to keep substantive discussion on the mailing list. If you see discussions that are more than merely administrative, please send a message to the list about them.

+1

Dave Rice

---

From: Reto Kromer <[email-masked]>
Date: Tue, 29 Dec 2015 19:48:18 +0100

+1

Best regards, Reto

> On 29.12.2015, at 18:27, Dave Rice <[email-masked]> wrote:
> 
> Hi,
>

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Tue, 29 Dec 2015 12:55:27 -0800

Dave Rice wrote:
> We have many works in progress for EBML, Matroska, FFV1 and FLAC.
> These are currently in GitHub repos, Drupal, or websites. At what
> point should they become 'working group drafts'? Is there a
> particular threshold in the work on these underlying documents to
> cross in order to be a working group draft?

An excellent question. RFC 7221 documents the criteria that are 
generally considered for adoption of a draft by a WG:
https://tools.ietf.org/html/rfc7221#section-2.2

Since we are not likely to see competing approaches for our various 
milestones, and the milestones themselves are pretty clear, I would say 
that for this group the two important questions are

1) "Does the document provide an acceptable platform for continued 
effort by the working group?"

and

2) "Is the draft likely to be completed in a timely manner?"

For example, a largely complete first draft (a few TODOs or missing 
sections would be fine, of course) with one or two clearly active 
authors would be a good basis to answer both of those questions in the 
affirmative.

 From a procedural point of view, the draft would have to be submitted 
to https://datatracker.ietf.org/submit/ in the usual I-D format. The 
actual source for the draft can continue to live in Github, or whatever 
is convenient. Once submitted, the chairs (Tessa and I) can issue a call 
for adoption, and if there is rough consensus, we will appoint editors 
and formally adopt the draft.