diff mbox series

[FFmpeg-devel,RFC,v3] Tech Resolution Process

Message ID 20210208142304.78634-1-jb@videolan.org
State Superseded
Headers show
Series [FFmpeg-devel,RFC,v3] Tech Resolution Process | expand

Checks

Context Check Description
andriy/x86_make success Make finished
andriy/x86_make_fate success Make fate finished
andriy/PPC64_make success Make finished
andriy/PPC64_make_fate success Make fate finished

Commit Message

Jean-Baptiste Kempf Feb. 8, 2021, 2:23 p.m. UTC
---
 doc/dev_community/resolution_process.md | 91 +++++++++++++++++++++++++
 1 file changed, 91 insertions(+)
 create mode 100644 doc/dev_community/resolution_process.md

Comments

Lynne Feb. 8, 2021, 7:13 p.m. UTC | #1
Feb 8, 2021, 15:23 by jb@videolan.org:

> ---
>  doc/dev_community/resolution_process.md | 91 +++++++++++++++++++++++++
>  1 file changed, 91 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..6da3e8ffb2
> --- /dev/null
> +++ b/doc/dev_community/resolution_process.md
> @@ -0,0 +1,91 @@
> +# 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
> +* may have an extra description, or a link to a previous discussion, if deemed necessary,
> +* 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, mails on the thread will be ignored.
> +
> +Violations of those rules will be escalated through the Community Committee.
> +
> +After all the emails are in, the TC has 96 hours to give its final decision.
> +Exceptionally, the TC can request an extra delay, that will be notified on the
> +mailing list.
> +
> +### Within TC
> +
> +In the internal case, the TC has 96 hours to give its final decision.
> +Exceptionally, the TC can request an extra delay.
> +
> +
> +## 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 decision from the TC should be published with a summary of the reasons that
> +lead to this decision.
> +
> +The decisions from the TC are final, until the matters are reopened after
> +no less than one year, by either the GA or the TC auto-seizing.
>

Is there an OR there? Can the question be raised again after more than
a year by anyone, OR at any time by either the GA or the TC?
Anton Khirnov Feb. 10, 2021, 10:45 a.m. UTC | #2
Quoting Lynne (2021-02-08 20:13:39)
> Feb 8, 2021, 15:23 by jb@videolan.org:
> > +
> > +The decisions from the TC are final, until the matters are reopened after
> > +no less than one year, by either the GA or the TC auto-seizing.
> >
> 
> Is there an OR there? Can the question be raised again after more than
> a year by anyone, OR at any time by either the GA or the TC?

I'd say after more than a year through the normal process. So best to
drop the part after the comma to avoid confusion.
Lynne Feb. 10, 2021, 1:15 p.m. UTC | #3
Feb 10, 2021, 11:45 by anton@khirnov.net:

> Quoting Lynne (2021-02-08 20:13:39)
>
>> Feb 8, 2021, 15:23 by jb@videolan.org:
>> > +
>> > +The decisions from the TC are final, until the matters are reopened after
>> > +no less than one year, by either the GA or the TC auto-seizing.
>> >
>>
>> Is there an OR there? Can the question be raised again after more than
>> a year by anyone, OR at any time by either the GA or the TC?
>>
>
> I'd say after more than a year through the normal process. So best to
> drop the part after the comma to avoid confusion.
>

I think an OR should be added. The TC or GA should be able to say
"oh, we really screwed it up, now it turns out we absolutely need this"
without waiting a full year.
Anton Khirnov Feb. 10, 2021, 1:34 p.m. UTC | #4
Quoting Lynne (2021-02-10 14:15:29)
> Feb 10, 2021, 11:45 by anton@khirnov.net:
> 
> > Quoting Lynne (2021-02-08 20:13:39)
> >
> >> Feb 8, 2021, 15:23 by jb@videolan.org:
> >> > +
> >> > +The decisions from the TC are final, until the matters are reopened after
> >> > +no less than one year, by either the GA or the TC auto-seizing.
> >> >
> >>
> >> Is there an OR there? Can the question be raised again after more than
> >> a year by anyone, OR at any time by either the GA or the TC?
> >>
> >
> > I'd say after more than a year through the normal process. So best to
> > drop the part after the comma to avoid confusion.
> >
> 
> I think an OR should be added. The TC or GA should be able to say
> "oh, we really screwed it up, now it turns out we absolutely need this"
> without waiting a full year.

It's redundant. GA can already vote on whatever it wants, all the rules
exist only because GA agrees on them.
And the cases of "we fucked up bad, absolutely need to change this"
should be rare enough to not need a special rule.
Lynne Feb. 10, 2021, 1:37 p.m. UTC | #5
Feb 10, 2021, 14:34 by anton@khirnov.net:

> Quoting Lynne (2021-02-10 14:15:29)
>
>> Feb 10, 2021, 11:45 by anton@khirnov.net:
>>
>> > Quoting Lynne (2021-02-08 20:13:39)
>> >
>> >> Feb 8, 2021, 15:23 by jb@videolan.org:
>> >> > +
>> >> > +The decisions from the TC are final, until the matters are reopened after
>> >> > +no less than one year, by either the GA or the TC auto-seizing.
>> >> >
>> >>
>> >> Is there an OR there? Can the question be raised again after more than
>> >> a year by anyone, OR at any time by either the GA or the TC?
>> >>
>> >
>> > I'd say after more than a year through the normal process. So best to
>> > drop the part after the comma to avoid confusion.
>> >
>>
>> I think an OR should be added. The TC or GA should be able to say
>> "oh, we really screwed it up, now it turns out we absolutely need this"
>> without waiting a full year.
>>
>
> It's redundant. GA can already vote on whatever it wants, all the rules
> exist only because GA agrees on them.
> And the cases of "we fucked up bad, absolutely need to change this"
> should be rare enough to not need a special rule.
>

Oh, sorry, I misread it as "drop the comma".
If the part after the comma is removed the document looks good to me.
diff mbox series

Patch

diff --git a/doc/dev_community/resolution_process.md b/doc/dev_community/resolution_process.md
new file mode 100644
index 0000000000..6da3e8ffb2
--- /dev/null
+++ b/doc/dev_community/resolution_process.md
@@ -0,0 +1,91 @@ 
+# 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
+* may have an extra description, or a link to a previous discussion, if deemed necessary,
+* 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, mails on the thread will be ignored.
+
+Violations of those rules will be escalated through the Community Committee.
+
+After all the emails are in, the TC has 96 hours to give its final decision.
+Exceptionally, the TC can request an extra delay, that will be notified on the
+mailing list.
+
+### Within TC
+
+In the internal case, the TC has 96 hours to give its final decision.
+Exceptionally, the TC can request an extra delay.
+
+
+## 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 decision from the TC should be published with a summary of the reasons that
+lead to this decision.
+
+The decisions from the TC are final, until the matters are reopened after
+no less than one year, by either the GA or the TC auto-seizing.
+