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

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

Jan 11, 2021, 14:03 by jb@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).



> +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".



> +
> +After all the emails are in, the TC has 96 hours to give its final decision.
> +Exceptionally, the TC can request an extra delay.
> +
> +### 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, the GA or the TC auto-seizing.
>

What was the GA again?
And the one year limit doesn't apply for the TC or the GA, right?

Quoting Jean-Baptiste Kempf (2021-01-11 14:03:42)
> ---
>  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.

This wasn't in the previous version IIRC, and does not seem reasonable
to me.
For one thing, it adds a possibility of a tie, which was impossible with
odd number of TC members.
For another, they are excluded from having a say precisely in those
matters where they have most expertise.

Quoting Lynne (2021-01-11 16:15:06)
> Jan 11, 2021, 14:03 by jb@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.

Jan 18, 2021, 12:59 by anton@khirnov.net:

> Quoting Lynne (2021-01-11 16:15:06)
>
>> Jan 11, 2021, 14:03 by jb@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.
>

That's not the same. What you'd like is a digest of the discussion,
not links to dozens of different threads and IRC logs to sift through.
Especially for devs don't keep up to date with the ML (because it's difficult).



>> > +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.
>

Or nothing at all if it's just a civilized intellectual discussion, or praise.
Hence no reason to have this rule at all.

Anton Khirnov (12021-01-18):
> This wasn't in the previous version IIRC, and does not seem reasonable
> to me.

It was added at my suggestion, AFAIK.

> For one thing, it adds a possibility of a tie, which was impossible with
> odd number of TC members.

Unless somebody abstains, which is always possible.

> For another, they are excluded from having a say precisely in those
> matters where they have most expertise.

And the matters where they are most biassed.

What we are talking about is called conflict of interest. Every
functioning institution has rules to prevent them. Let us not manage to
be a non-functioning institution from the get go.

Regards,

Hi,

On Mon, Jan 18, 2021 at 1:25 PM Nicolas George <george@nsup.org> wrote:

> What we are talking about is called conflict of interest. Every
> functioning institution has rules to prevent them.


+1 on this.

Ronald

On Mon, Jan 18, 2021 at 7:49 PM Ronald S. Bultje <rsbultje@gmail.com> wrote:

> Hi,
>
> On Mon, Jan 18, 2021 at 1:25 PM Nicolas George <george@nsup.org> wrote:
>
> > What we are talking about is called conflict of interest. Every
> > functioning institution has rules to prevent them.
>
>
> +1 on this.
>

How do you want to prevent such conflicts of interest?


>
> Ronald
> _______________________________________________
> 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".

Quoting Nicolas George (2021-01-18 19:25:39)
> Anton Khirnov (12021-01-18):
> > For another, they are excluded from having a say precisely in those
> > matters where they have most expertise.
> 
> And the matters where they are most biassed.
> 
> What we are talking about is called conflict of interest. Every
> functioning institution has rules to prevent them. Let us not manage to
> be a non-functioning institution from the get go.

How do you distinguish between "having a legitimate technical opinion"
from "being biased"? Seems to me it's purely in the eye of the beholder.

I don't think the notion of a conflict of interest applies here, since
TC members do not get any personal gain from it, other than being able
to steer the project direction. But since that is the entire point of
making someone a TC member, it makes no sense to take that power away
from them.

I have at some point touched most major pieces of code in the project.
I also have opinions on how many things should be done. So according to
your definition, that makes me biased and disqualified from voting on
almost anything, so there is no point in me being a TC member. Same
applies to Michael.

Hi,

On Mon, Jan 18, 2021 at 2:55 PM Anton Khirnov <anton@khirnov.net> wrote:

> I have at some point touched most major pieces of code in the project.
> I also have opinions on how many things should be done. So according to
> your definition, that makes me biased and disqualified from voting on
> almost anything, so there is no point in me being a TC member. Same
> applies to Michael.


But neither disqualifies you. TC is invoked when a specific unresolvable
disagreement arises between two developers. A TC member should not vote if
he is one of these two people.

Or did you mean something else?

Ronald

Quoting Ronald S. Bultje (2021-01-18 21:12:50)
> Hi,
> 
> On Mon, Jan 18, 2021 at 2:55 PM Anton Khirnov <anton@khirnov.net> wrote:
> 
> > I have at some point touched most major pieces of code in the project.
> > I also have opinions on how many things should be done. So according to
> > your definition, that makes me biased and disqualified from voting on
> > almost anything, so there is no point in me being a TC member. Same
> > applies to Michael.
> 
> 
> But neither disqualifies you. TC is invoked when a specific unresolvable
> disagreement arises between two developers. A TC member should not vote if
> he is one of these two people.
> 
> Or did you mean something else?

Doesn't have to be two people. IIUC in the model situation there is a
disagreement on the mailing list where a consensus cannot be reached. So
potentially many people commenting. You could say that any one of them
is "involved".

On Mon, Jan 18, 2021 at 3:33 PM Anton Khirnov <anton@khirnov.net> wrote:

> Quoting Ronald S. Bultje (2021-01-18 21:12:50)
> > Hi,
> >
> > On Mon, Jan 18, 2021 at 2:55 PM Anton Khirnov <anton@khirnov.net> wrote:
> >
> > > I have at some point touched most major pieces of code in the project.
> > > I also have opinions on how many things should be done. So according to
> > > your definition, that makes me biased and disqualified from voting on
> > > almost anything, so there is no point in me being a TC member. Same
> > > applies to Michael.
> >
> >
> > But neither disqualifies you. TC is invoked when a specific unresolvable
> > disagreement arises between two developers. A TC member should not vote
> if
> > he is one of these two people.
> >
> > Or did you mean something else?
>
> Doesn't have to be two people. IIUC in the model situation there is a
> disagreement on the mailing list where a consensus cannot be reached. So
> potentially many people commenting. You could say that any one of them
> is "involved".


I agree "involved" should be constrained to just be one of the two parties
bringing this up to the TC. And yes this can be gamed, everything can. It's
meant to prevent extreme cases, not make the world a perfect place. We
can't do that with rules alone.

Ronald

Ronald S. Bultje (12021-01-18):
> I agree "involved" should be constrained to just be one of the two parties
> bringing this up to the TC. And yes this can be gamed, everything can. It's
> meant to prevent extreme cases, not make the world a perfect place. We
> can't do that with rules alone.

I agree with all this.

I would say that if "you" are part of an argument, you should know it.
And if you have doubt, that means you probably are, and you should err
on the side of caution and recuse yourself. After all, recusing oneself
uselessly only means a little more work for the other members of the
committee while not doing it when needed undermines the trust in the
process.

Let us remember that this committee is about serving the community by
resolving conflicts, it is definitely not about personal power for the
members.

For it to work properly, technical competence is necessary, but
technical expertise is much less important than honesty and willingness
to listen.

Regards,

On Tue, Jan 19, 2021 at 5:26 PM Nicolas George <george@nsup.org> wrote:

> Ronald S. Bultje (12021-01-18):
> > I agree "involved" should be constrained to just be one of the two
> parties
> > bringing this up to the TC. And yes this can be gamed, everything can.
> It's
> > meant to prevent extreme cases, not make the world a perfect place. We
> > can't do that with rules alone.
>
> I agree with all this.
>
> I would say that if "you" are part of an argument, you should know it.
> And if you have doubt, that means you probably are, and you should err
> on the side of caution and recuse yourself. After all, recusing oneself
> uselessly only means a little more work for the other members of the
> committee while not doing it when needed undermines the trust in the
> process.
>
> Let us remember that this committee is about serving the community by
> resolving conflicts, it is definitely not about personal power for the
> members.
>
> For it to work properly, technical competence is necessary, but
> technical expertise is much less important than honesty and willingness
> to listen.
>
>
Listen to whom? And honest about what?


> Regards,
>
> --
>   Nicolas George
> _______________________________________________
> 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".