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

[Nicolas George]

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,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20201206/a0f84356/attachment.sig>