[FFmpeg-devel,PATCHv2] Document community process

General Assembly + Main Elections
---
 doc/dev_community/community.md | 80 ++++++++++++++++++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 doc/dev_community/community.md

> 2020年10月12日 下午3:35，Jean-Baptiste Kempf <jb@videolan.org> 写道：
> 
> General Assembly + Main Elections
> ---
> doc/dev_community/community.md | 80 ++++++++++++++++++++++++++++++++++
> 1 file changed, 80 insertions(+)
> create mode 100644 doc/dev_community/community.md
> 
> diff --git a/doc/dev_community/community.md b/doc/dev_community/community.md
> new file mode 100644
> index 0000000000..2ce3aa0b30
> --- /dev/null
> +++ b/doc/dev_community/community.md
> @@ -0,0 +1,80 @@
> +# FFmpeg project
> +
> +## Organisation
> +
> +The FFmpeg project is organized through a community working on global consensus.
> +
> +Decisions are taken by the ensemble of active members, through voting and
> +are aided by two committees.
> +
> +## General Assembly
> +
> +The ensemble of active members is called the General Assembly (GA).
> +
> +The General Assembly is sovereign and legitimate for all its decisions
> +regarding the FFmpeg project.
> +
> +The General Assembly is made up of active contributors.
> +
> +Contributors are considered "active contributors" if they have pushed more
> +than 20 patches in the last 36 months in the main FFmpeg repository, or
> +if they have been voted in by the GA.
> +
> +Additional members are added to the General Assembly through a vote after
> +proposal by a member of the General Assembly.
> +They are part of the GA for two years, after which they need a confirmation by
> +the GA.
> +
> +## Voting
> +
> +Voting is done using a ranked voting system, currently running on https://vote.ffmpeg.org/ .
Hi JB,

	I cannot sure if vote.ffmpeg.org denny my IP,
	When I click this link, the web return:
	502 Bad Gateway

nginx/1.10.3 (Ubuntu)


> +
> +Majority vote means more than 50% of the expressed ballots.
> +
> +## Technical Committee
> +
> +The Technical Committee (TC) is here to arbitrate and make decisions when
> +technical conflicts occur in the project.
> +They will consider the merits of all the positions, judge them and make a
> +decision.
> +
> +The TC resolves technical conflicts but is not a technical steering committee.
> +
> +Decisions by the TC are binding for all the contributors.
> +
> +Decisions made by the TC can be re-opened after 1 year or by a majority vote
> +of the General Assembly, requested by one of the member of the GA.
> +
> +The TC is elected by the General Assembly for a duration of 1 year, and
> +is composed of 5 members.
> +Members can be re-elected if they wish. A majority vote in the General Assembly
> +can trigger a new election of the TC.
> +
> +The members of the TC can be elected from outside of the GA.
> +Candidates for election can either be suggested or self-nominated.
> +
> +The conflict resolution process is detailed in the [resolution process] document.
> +
> +## Community committee
> +
> +The Community Committee (CC) is here to arbitrage and make decisions when
> +inter-personal conflicts occur in the project. It will decide quickly and
> +take actions, for the sake of the project.
> +
> +The CC can remove privileges of offending members, including removal of
> +commit access and temporary ban from the community.
> +
> +Decisions made by the CC can be re-opened after 1 year or by a majority vote
> +of the General Assembly. Indefinite bans from the community must be confirmed
> +by the General Assembly, in a majority vote.
> +
> +The CC is elected by the General Assembly for a duration of 1 year, and is
> +composed of 5 members.
> +Members can be re-elected if they wish. A majority vote in the General Assembly
> +can trigger a new election of the CC.
> +
> +The members of the CC can be elected from outside of the GA.
> +Candidates for election can either be suggested or self-nominated.
> +
> +The CC is governed by and responsible for enforcing the Code of Conduct.
> +
> -- 
> 2.28.0
> 
> _______________________________________________
> 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".

Thanks

Steven Liu

On Mon, 12 Oct 2020, at 11:28, Steven Liu wrote:
> > +Voting is done using a ranked voting system, currently running on https://vote.ffmpeg.org/ .
> Hi JB,
> 
> 	I cannot sure if vote.ffmpeg.org denny my IP,
> 	When I click this link, the web return:
> 	502 Bad Gateway
> 
> nginx/1.10.3 (Ubuntu)

Yeah, it is currently down (we don't have a vote), but I'll see with Thilo.

Am 12.10.20 um 11:34 schrieb Jean-Baptiste Kempf:
> 
> On Mon, 12 Oct 2020, at 11:28, Steven Liu wrote:
>>> +Voting is done using a ranked voting system, currently running on https://vote.ffmpeg.org/ .
>> Hi JB,
>>
>> 	I cannot sure if vote.ffmpeg.org denny my IP,
>> 	When I click this link, the web return:
>> 	502 Bad Gateway
>>
>> nginx/1.10.3 (Ubuntu)
> 
> Yeah, it is currently down (we don't have a vote), but I'll see with Thilo.

vote.ffmpeg.org is up and running again.

-Thilo

mån 2020-10-12 klockan 09:35 +0200 skrev Jean-Baptiste Kempf:
> +Contributors are considered "active contributors" if they have pushed more
> +than 20 patches in the last 36 months in the main FFmpeg repository, or
> +if they have been voted in by the GA.

This might be a problem for parts of the code which see patches only
sporadically, like the MXF stuff me and Baptiste maintain. Probably
unlikely that the TC overrides devs with domain expertise, but I raise
it as a potential issue anyway.

/Tomas

On Mon, 12 Oct 2020, at 20:34, Tomas Härdin wrote:
> mån 2020-10-12 klockan 09:35 +0200 skrev Jean-Baptiste Kempf:
> > +Contributors are considered "active contributors" if they have pushed more
> > +than 20 patches in the last 36 months in the main FFmpeg repository, or
> > +if they have been voted in by the GA.
> 
> This might be a problem for parts of the code which see patches only
> sporadically, like the MXF stuff me and Baptiste maintain. Probably
> unlikely that the TC overrides devs with domain expertise, but I raise
> it as a potential issue anyway.

This is a known issue that might arise, but we had to draw a line.
Note that you can always voted in as "extra members" if requested.

mån 2020-10-12 klockan 21:31 +0200 skrev Jean-Baptiste Kempf:
> On Mon, 12 Oct 2020, at 20:34, Tomas Härdin wrote:
> > mån 2020-10-12 klockan 09:35 +0200 skrev Jean-Baptiste Kempf:
> > > +Contributors are considered "active contributors" if they have pushed more
> > > +than 20 patches in the last 36 months in the main FFmpeg repository, or
> > > +if they have been voted in by the GA.
> > 
> > This might be a problem for parts of the code which see patches only
> > sporadically, like the MXF stuff me and Baptiste maintain. Probably
> > unlikely that the TC overrides devs with domain expertise, but I raise
> > it as a potential issue anyway.
> 
> This is a known issue that might arise, but we had to draw a line.
> Note that you can always voted in as "extra members" if requested.

Fair enough.

/Tomas

Am 12.10.20 um 09:35 schrieb Jean-Baptiste Kempf:
> General Assembly + Main Elections
> ---
>  doc/dev_community/community.md | 80 ++++++++++++++++++++++++++++++++++
>  1 file changed, 80 insertions(+)
>  create mode 100644 doc/dev_community/community.md

pushed. Thx!

-Thilo

On Mon, Oct 12, 2020 at 09:35:57AM +0200, Jean-Baptiste Kempf wrote:
> General Assembly + Main Elections
> ---
>  doc/dev_community/community.md | 80 ++++++++++++++++++++++++++++++++++
>  1 file changed, 80 insertions(+)
>  create mode 100644 doc/dev_community/community.md
> 
> diff --git a/doc/dev_community/community.md b/doc/dev_community/community.md
> new file mode 100644
> index 0000000000..2ce3aa0b30
> --- /dev/null
> +++ b/doc/dev_community/community.md
> @@ -0,0 +1,80 @@
> +# FFmpeg project
> +
> +## Organisation
> +
> +The FFmpeg project is organized through a community working on global consensus.
> +
> +Decisions are taken by the ensemble of active members, through voting and
> +are aided by two committees.
> +
> +## General Assembly
> +
> +The ensemble of active members is called the General Assembly (GA).
> +
> +The General Assembly is sovereign and legitimate for all its decisions
> +regarding the FFmpeg project.
> +
> +The General Assembly is made up of active contributors.
> +
> +Contributors are considered "active contributors" if they have pushed more
> +than 20 patches in the last 36 months in the main FFmpeg repository, or
> +if they have been voted in by the GA.
> +
> +Additional members are added to the General Assembly through a vote after
> +proposal by a member of the General Assembly.
> +They are part of the GA for two years, after which they need a confirmation by
> +the GA.
> +
> +## Voting
> +

> +Voting is done using a ranked voting system, currently running on https://vote.ffmpeg.org/ .

I think Voting should be defined more precissely


thx

[...]

Yo,

On Mon, 19 Oct 2020, at 19:02, Michael Niedermayer wrote:
> > +## Voting
> > +
> 
> > +Voting is done using a ranked voting system, currently running on https://vote.ffmpeg.org/ .
> 
> I think Voting should be defined more precissely

That's a good point. What would like to see here? The algo used? The software used?

--
Jean-Baptiste Kempf -  President
+33 672 704 734

On Mon, Oct 19, 2020 at 07:22:48PM +0200, Jean-Baptiste Kempf wrote:
> Yo,
> 
> On Mon, 19 Oct 2020, at 19:02, Michael Niedermayer wrote:
> > > +## Voting
> > > +
> > 
> > > +Voting is done using a ranked voting system, currently running on https://vote.ffmpeg.org/ .
> > 
> > I think Voting should be defined more precissely
> 
> That's a good point. What would like to see here? The algo used? The software used?

I dont know what is best.

What is the goal having this information there serves ?
I think there are 3 or 4 levels/classes of information that could be provided
at highest level, listing the properties of the vote system

A.
(this is not intended to be an exhaustive list but rather list the points
 which actually change the real world behavior of the vote)
For example does it conform to to the condorcet criterion for single winner
elections
Or with multiwinner elections, is there some sort of proportionality, that is
can 51% of voters control all seats or can any 20% of voters generally 
control one of 5 seats.

B.
at the next lower level, the academic algorithm could be referenced, this 
would give enough information to reproduce most votes but ties and corner
cases might not be fully defined

C.
nipickingly precissely define the algorithm so that any list of ballots
produces a clear and reproducable result or failure, tie resolution rules, ...

D.
Refer to an actual implementation

Possible goals:
understanding on the readers side of the general vote algorithm behavior, not leaving it a black box.
reproducability
avoiding disputes
keeping the text simple
allowing changes if things turn out to go wrong in some way

thx

[...]

Quoting Michael Niedermayer (2020-10-19 23:57:31)
> On Mon, Oct 19, 2020 at 07:22:48PM +0200, Jean-Baptiste Kempf wrote:
> > Yo,
> > 
> > On Mon, 19 Oct 2020, at 19:02, Michael Niedermayer wrote:
> > > > +## Voting
> > > > +
> > > 
> > > > +Voting is done using a ranked voting system, currently running on https://vote.ffmpeg.org/ .
> > > 
> > > I think Voting should be defined more precissely
> > 
> > That's a good point. What would like to see here? The algo used? The software used?
> 
> I dont know what is best.
> 
> What is the goal having this information there serves ?
> I think there are 3 or 4 levels/classes of information that could be provided
> at highest level, listing the properties of the vote system

In my view, this documented is intended to serve mainly as a statement
of intent rather than a strict legalistic definition of everything, so
it would be sufficient to mention that we are using a ranked Condorcet
method. I would think very few developers know or care what the exact
differences between the methods are, as long as they are in some sense
"reasonable".

On Sun, Oct 25, 2020 at 01:55:11PM +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2020-10-19 23:57:31)
> > On Mon, Oct 19, 2020 at 07:22:48PM +0200, Jean-Baptiste Kempf wrote:
> > > Yo,
> > > 
> > > On Mon, 19 Oct 2020, at 19:02, Michael Niedermayer wrote:
> > > > > +## Voting
> > > > > +
> > > > 
> > > > > +Voting is done using a ranked voting system, currently running on https://vote.ffmpeg.org/ .
> > > > 
> > > > I think Voting should be defined more precissely
> > > 
> > > That's a good point. What would like to see here? The algo used? The software used?
> > 
> > I dont know what is best.
> > 
> > What is the goal having this information there serves ?
> > I think there are 3 or 4 levels/classes of information that could be provided
> > at highest level, listing the properties of the vote system
> 
> In my view, this documented is intended to serve mainly as a statement
> of intent rather than a strict legalistic definition of everything, so
> it would be sufficient to mention that we are using a ranked Condorcet
> method. I would think very few developers know or care what the exact
> differences between the methods are, as long as they are in some sense
> "reasonable".

The problem is elections with multiple winners, That is elections of seats
in a committee or other group.
Consider a 5 seat comittee
and lets consider that there are blue and pink candidates
if you have 100 people voting and 51 of them vote only for pink candidates and
49 only for blue candidates.
repeated application of a Condorcet method will give you 5 pink candidates

OTOH something like schulze STV, also a Condorcet method should in this case
give you 3 pink candidates and 2 blue ones.

The above is a bit oversimplified but basically there are 2 classes of voting
systems. The first class is applying single winner election methods repeatedly
to fill all seats. 
The other is trying to fill seats so they are representing the set of voters.

The first class can skip over minorities even when they are quite large,
but the people choosen should have "strong and maximal support"

The second class would favor creating a representative set over one of
maximal support by voters. It could lead to a more "colorfull" result
with seats filled by people representing minortes and lacking broad support.

The results likely will differ in reallity as well.

We dont have to write this down in "this" document but we should
write it down in some document if what is considered "reasonable"
is "Proportional representation" or not.

What i can say is that if we want a 
* "Proportional representation" system
 then schulze STV is a "beatifull" system free of ugly discrete choices like STV 
 and its also condorcet
* non "Proportional representation".
 then normal repeatly applying the normal schulze method is the obvious choice

IIUC CIVS supports repeatly applying the normal schulze method and thilo added
support for schulze STV

thx

[...]

Quoting Michael Niedermayer (2020-10-26 19:01:47)
> On Sun, Oct 25, 2020 at 01:55:11PM +0100, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2020-10-19 23:57:31)
> > > On Mon, Oct 19, 2020 at 07:22:48PM +0200, Jean-Baptiste Kempf wrote:
> > > > Yo,
> > > > 
> > > > On Mon, 19 Oct 2020, at 19:02, Michael Niedermayer wrote:
> > > > > > +## Voting
> > > > > > +
> > > > > 
> > > > > > +Voting is done using a ranked voting system, currently running on https://vote.ffmpeg.org/ .
> > > > > 
> > > > > I think Voting should be defined more precissely
> > > > 
> > > > That's a good point. What would like to see here? The algo used? The software used?
> > > 
> > > I dont know what is best.
> > > 
> > > What is the goal having this information there serves ?
> > > I think there are 3 or 4 levels/classes of information that could be provided
> > > at highest level, listing the properties of the vote system
> > 
> > In my view, this documented is intended to serve mainly as a statement
> > of intent rather than a strict legalistic definition of everything, so
> > it would be sufficient to mention that we are using a ranked Condorcet
> > method. I would think very few developers know or care what the exact
> > differences between the methods are, as long as they are in some sense
> > "reasonable".
> 
> The problem is elections with multiple winners, That is elections of seats
> in a committee or other group.
> Consider a 5 seat comittee
> and lets consider that there are blue and pink candidates
> if you have 100 people voting and 51 of them vote only for pink candidates and
> 49 only for blue candidates.
> repeated application of a Condorcet method will give you 5 pink candidates
> 
> OTOH something like schulze STV, also a Condorcet method should in this case
> give you 3 pink candidates and 2 blue ones.
> 
> The above is a bit oversimplified but basically there are 2 classes of voting
> systems. The first class is applying single winner election methods repeatedly
> to fill all seats. 
> The other is trying to fill seats so they are representing the set of voters.
> 
> The first class can skip over minorities even when they are quite large,
> but the people choosen should have "strong and maximal support"
> 
> The second class would favor creating a representative set over one of
> maximal support by voters. It could lead to a more "colorfull" result
> with seats filled by people representing minortes and lacking broad support.
> 
> The results likely will differ in reallity as well.
> 
> We dont have to write this down in "this" document but we should
> write it down in some document if what is considered "reasonable"
> is "Proportional representation" or not.
> 
> What i can say is that if we want a 
> * "Proportional representation" system
>  then schulze STV is a "beatifull" system free of ugly discrete choices like STV 
>  and its also condorcet
> * non "Proportional representation".
>  then normal repeatly applying the normal schulze method is the obvious choice
> 
> IIUC CIVS supports repeatly applying the normal schulze method and thilo added
> support for schulze STV

AFAIU we used schulze STV for the votes so far, right? So it seems
reasonable to continue with that unless there are significant objections.

Generally I agree with your points, but IMO this should be in a separate
document that describes the "technicalities" of the development process.

On Tue, Oct 27, 2020 at 11:07:23AM +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2020-10-26 19:01:47)
> > On Sun, Oct 25, 2020 at 01:55:11PM +0100, Anton Khirnov wrote:
> > > Quoting Michael Niedermayer (2020-10-19 23:57:31)
> > > > On Mon, Oct 19, 2020 at 07:22:48PM +0200, Jean-Baptiste Kempf wrote:
> > > > > Yo,
> > > > > 
> > > > > On Mon, 19 Oct 2020, at 19:02, Michael Niedermayer wrote:
> > > > > > > +## Voting
> > > > > > > +
> > > > > > 
> > > > > > > +Voting is done using a ranked voting system, currently running on https://vote.ffmpeg.org/ .
> > > > > > 
> > > > > > I think Voting should be defined more precissely
> > > > > 
> > > > > That's a good point. What would like to see here? The algo used? The software used?
> > > > 
> > > > I dont know what is best.
> > > > 
> > > > What is the goal having this information there serves ?
> > > > I think there are 3 or 4 levels/classes of information that could be provided
> > > > at highest level, listing the properties of the vote system
> > > 
> > > In my view, this documented is intended to serve mainly as a statement
> > > of intent rather than a strict legalistic definition of everything, so
> > > it would be sufficient to mention that we are using a ranked Condorcet
> > > method. I would think very few developers know or care what the exact
> > > differences between the methods are, as long as they are in some sense
> > > "reasonable".
> > 
> > The problem is elections with multiple winners, That is elections of seats
> > in a committee or other group.
> > Consider a 5 seat comittee
> > and lets consider that there are blue and pink candidates
> > if you have 100 people voting and 51 of them vote only for pink candidates and
> > 49 only for blue candidates.
> > repeated application of a Condorcet method will give you 5 pink candidates
> > 
> > OTOH something like schulze STV, also a Condorcet method should in this case
> > give you 3 pink candidates and 2 blue ones.
> > 
> > The above is a bit oversimplified but basically there are 2 classes of voting
> > systems. The first class is applying single winner election methods repeatedly
> > to fill all seats. 
> > The other is trying to fill seats so they are representing the set of voters.
> > 
> > The first class can skip over minorities even when they are quite large,
> > but the people choosen should have "strong and maximal support"
> > 
> > The second class would favor creating a representative set over one of
> > maximal support by voters. It could lead to a more "colorfull" result
> > with seats filled by people representing minortes and lacking broad support.
> > 
> > The results likely will differ in reallity as well.
> > 
> > We dont have to write this down in "this" document but we should
> > write it down in some document if what is considered "reasonable"
> > is "Proportional representation" or not.
> > 
> > What i can say is that if we want a 
> > * "Proportional representation" system
> >  then schulze STV is a "beatifull" system free of ugly discrete choices like STV 
> >  and its also condorcet
> > * non "Proportional representation".
> >  then normal repeatly applying the normal schulze method is the obvious choice
> > 
> > IIUC CIVS supports repeatly applying the normal schulze method and thilo added
> > support for schulze STV
> 

> AFAIU we used schulze STV for the votes so far, right? So it seems

do you think this ? hope it ? or did you check it ?
 

> reasonable to continue with that unless there are significant objections.
> 
> Generally I agree with your points, but IMO this should be in a separate
> document that describes the "technicalities" of the development process.

sure, i have no oppinion on where to put it.

thx

[...]

On Tue, 27 Oct 2020, at 18:02, Michael Niedermayer wrote:
> > AFAIU we used schulze STV for the votes so far, right? So it seems
> 
> do you think this ? hope it ? or did you check it ?

All the methods gave the same results.

--
Jean-Baptiste Kempf -  President
+33 672 704 734

Quoting Michael Niedermayer (2020-10-27 18:02:46)
> 
> > AFAIU we used schulze STV for the votes so far, right? So it seems
> 
> do you think this ? hope it ? or did you check it ?

It was my impression, because as I recall the vote was postponed so that
this method could be added to the software.
In any case, I don't think we are in disagreement on anything here.