Quoting Lynne (2021-01-11 16:15:06) > Jan 11, 2021, 14:03 by j...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".