Message ID | 20210211104620.65505-1-jb@videolan.org |
---|---|
State | New |
Headers | show |
Series | [FFmpeg-devel,RFC,v4] Tech Resolution Process | expand |
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 |
Hello, If you are a voter part of the FFmpeg General Assembly, you should have received an email to allow you to vote on this. Best, On Thu, 11 Feb 2021, at 11:46, Jean-Baptiste Kempf wrote: > --- > 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..4ed0b63c43 > --- /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. > + > -- > 2.30.0 > >
What is ranked choice voting?
On Mon, 1 Mar 2021, at 15:48, Paul B Mahol wrote:
> What is ranked choice voting?
https://ballotpedia.org/Ranked-choice_voting_(RCV)
For a binary vote, though, the interest is limited :)
Hello, This is a reminder about the vote. This is closing soon, and most of you have not voted yet! Best, On Mon, 1 Mar 2021, at 15:29, Jean-Baptiste Kempf wrote: > Hello, > > If you are a voter part of the FFmpeg General Assembly, you should have > received an email to allow you to vote on this. > > Best, > > On Thu, 11 Feb 2021, at 11:46, Jean-Baptiste Kempf wrote: > > --- > > 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..4ed0b63c43 > > --- /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. > > + > > -- > > 2.30.0 > > > > > > -- > Jean-Baptiste Kempf - President > +33 672 704 734 > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
diff --git a/doc/dev_community/resolution_process.md b/doc/dev_community/resolution_process.md new file mode 100644 index 0000000000..4ed0b63c43 --- /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. +