[FFmpeg-devel] [PATCHv2] Document community process

[Anton Khirnov]

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.

-- 
Anton Khirnov