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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
