[FFmpeg-devel,RFC] Tech Resolution Process

---
 doc/dev_community/resolution_process.md | 83 +++++++++++++++++++++++++
 1 file changed, 83 insertions(+)
 create mode 100644 doc/dev_community/resolution_process.md

Hi,

Le sam. 5 déc. 2020 à 15:59, Jean-Baptiste Kempf <jb@videolan.org> a écrit :
> +After all the emails are in, the TC has 96 hours to give its final decision.
> +
> +### Within TC
> +
> +In the internal case, the TC has 96 hours to give its final decision.

How is the unavailability of any TC member handled? What about a
quorum? Would you have deputy ("fallback") TC members then?
The unavailability can just be because the weekend falls in this 96H
period, but special (bank or not) holidays also.

Jean-Baptiste Kempf (12020-12-05):
> ---
>  doc/dev_community/resolution_process.md | 83 +++++++++++++++++++++++++
>  1 file changed, 83 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..0df584bae4
> --- /dev/null
> +++ b/doc/dev_community/resolution_process.md
> @@ -0,0 +1,83 @@
> +# 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.

I think another clause is needed around here:

# If the disagreement involves a member of the TC, that member must recuse
# themselves from the internal discussion and the decision vote.

> +
> +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.
> +
> +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 give a ban of the mailing-list.

This sounds harsh and unnecessary. What are the reasons for these
limits?

> +
> +After all the emails are in, the TC has 96 hours to give its final decision.
> +
> +### Within TC
> +
> +In the internal case, the TC has 96 hours to give its final decision.
> +
> +
> +## Decisions
> +
> +The decisions from the TC will be sent on the mailing list, with the _[TC]_ tag.
> +
> +Internally, the TC should take decisions with a majority, or using
> +ranked-choice voting.
> +

> +The reasons for the decisions from the TC can be kept internal by the TC,
> +if deemed necessary.

This feels shady. I suggest to reverse the wording, and make it much
stronger:

# The decision of the TC is published along with a summary of the reasons
# that lead to the decision, and the archives of the internal discussion
# are made available. If there are sensitive pieces of information, they
# can be withheld on an exceptional basis, and a convincing reason must be
# given.

The TC is there to resolve conflicts over technical questions between
developers, not to make them worse with secretive dictatorial practices
and arbitrary decisions.

> +
> +The decisions from the TC are final, until the matters are reopened after
> +no less than one year, the GA or the TC auto-seizing.

Regards,

On Sun, 6 Dec 2020, at 15:10, Nicolas George wrote:
> I think another clause is needed around here:

Added.

> > +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 give a ban of the mailing-list.
> 
> This sounds harsh and unnecessary. What are the reasons for these
> limits?

Removed for the ban part.

The limits are to ensure this does not get into another discussion/fight on the topic, which should have been done before.
This is to collect opinions, not restart the discussion.

> > +The reasons for the decisions from the TC can be kept internal by the TC,
> > +if deemed necessary.
> 
> This feels shady. I suggest to reverse the wording, and make it much
> stronger:
> 
> # The decision of the TC is published along with a summary of the reasons
> # that lead to the decision, 

Added.

> and the archives of the internal discussion
> # are made available. 

Personal emails must stay personal.
And it can be done through other communications means, like Phone, or RTC, or IRC queries...

They must explain their reasons, but they should be allow to discuss freely.