[FFmpeg-devel] [PATCH] [RFC][v2] Tech Resolution Process

[Anton Khirnov]

Quoting Lynne (2021-01-11 16:15:06)
> Jan 11, 2021, 14:03 by jb at videolan.org:
> 
> > ---
> >  doc/dev_community/resolution_process.md | 89 +++++++++++++++++++++++++
> >  1 file changed, 89 insertions(+)
> >  create mode 100644 doc/dev_community/resolution_process.md
> >
> > diff --git a/doc/dev_community/resolution_process.md b/doc/dev_community/resolution_process.md
> > new file mode 100644
> > index 0000000000..91999202cb
> > --- /dev/null
> > +++ b/doc/dev_community/resolution_process.md
> > @@ -0,0 +1,89 @@
> > +# Technical Committee
> > +
> > +_This document only makes sense with the rules from [the community document](community)_.
> > +
> > +The Technical Committee (**TC**) is here to arbitrate and make decisions when
> > +technical conflicts occur in the project.
> > +
> > +The TC main role is to resolve technical conflicts.
> > +It is therefore not a technical steering committee, but it is understood that
> > +some decisions might impact the future of the project.
> > +
> > +# Process
> > +
> > +## Seizing
> > +
> > +The TC can take possession of any technical matter that it sees fit.
> > +
> > +To involve the TC in a matter, email tc@ or CC them on an ongoing discussion.
> > +
> > +As members of TC are developers, they also can email tc@ to raise an issue.
> > +
> > +## Announcement
> > +
> > +The TC, once seized, must announce itself on the main mailing list, with a _[TC]_ tag.
> > +
> > +The TC has 2 modes of operation: a RFC one and an internal one.
> > +
> > +If the TC thinks it needs the input from the larger community, the TC can call
> > +for a RFC. Else, it can decide by itself.
> > +
> > +If the disagreement involves a member of the TC, that member should recuse
> > +themselves from the decision.
> > +
> > +The decision to use a RFC process or an internal discussion is a discretionary
> > +decision of the TC.
> > +
> > +The TC can also reject a seizure for a few reasons such as:
> > +the matter was not discussed enough previously; it lacks expertise to reach a
> > +beneficial decision on the matter; or the matter is too trivial.
> > +
> > +### RFC call
> > +
> > +In the RFC mode, one person from the TC posts on the mailing list the
> > +technical question and will request input from the community.
> > +
> > +The mail will have the following specification:
> > +* a precise title
> > +* a specific tag [TC RFC]
> > +* a top-level email
> > +* contain a precise question that does not exceed 100 words and that is answerable by developers
> > +* contain a precise end date for the answers.
> >
> Add a line like "may have a description of unlimited length".
> So only the question part is limited to 100 words, while the description
> may be as long as necessary as long as its separate (e.g. in another paragraph).

IIUC the idea is that the topic has already been discussed on the ML
previously and all opinions have been gathered, before it is submitted
to TC. TC is a last resort.
So the question can just link to the relevant discussion.

> 
> 
> 
> > +The answers from the community must be on the main mailing list and must have
> > +the following specification:
> > +* keep the tag and the title unchanged
> > +* limited to 400 words
> > +* a first-level, answering directly to the main email
> > +* answering to the question.
> > +
> > +Further replies to answers are permitted, as long as they conform to the
> > +community standards of politeness, they are limited to 100 words, and are not
> > +nested more than once. (max-depth=2)
> > +
> > +After the end-date, no mail on the thread is accepted.
> > +
> > +Violations of this rule will escalated through the Community Committee.
> >
> That seems a bit harsh. Posting after the end-date should be acceptable
> so long as a reasonable standard of conversation is maintained.
> Working around this by not posting on the thread would also work.
> Just remove this rule or modify it like "posts after the end-date will
> be ignored by the TC".

Doesn't mean the CC has to do anything beyond a warning.

-- 
Anton Khirnov