[FFmpeg-devel] [PATCHv2] Document community process

[Michael Niedermayer]

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

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20201027/e1691ebf/attachment.sig>