[FFmpeg-devel] Voting committee

[Thilo Borgmann]

Am 16.09.15 um 09:04 schrieb anshul:
> 
> 
> On Monday 14 September 2015 10:50 PM, Nicolas George wrote:
>> L'octidi 28 fructidor, an CCXXIII, Ganesh Ajjanagadde a écrit :
>>> Looks mostly good to me. One thing I think that should be clarified is
>>> the meaning of "linear combination" - I assume you meant a non-trivial
>>> (exclude all zeros) linear combination over the nonnegative integers?
>> Thanks. You are right, this was imprecise. I meant linear combination with
>> total coefficients one; barycenter in other words. For example: 10 commits
>> are ok, 20 devel mails are ok, then 5 commits and 10 devel mails are ok too.
>>
>> Of course, the value I have put are rather arbitrary. Please people feel
>> free to propose other values.
>>
>> Regards,
>>
>>
> Some thoughts on voting commitee:
> It looks like maintainer list is ignored. Like if there is maintainer of XYZ
> feature. and decision of XYZ features are taken by committee then ignoring him
> just because he don't have lots of commit would be bad idea. Maintainer has
> taken responsibility so until he is not removed from maintainer list from that
> part and his place is not filled by someone else.
> 
> There could be conflicts like if XYZ part is not developed well or used by many
> people take snow or ffserver for example people want to remove it completely.
> Since majority of comitee don't like that feature then that does not mean that
> they are authorized to remove that part. If there is no maintainer for some part
> they can remove it to decrease work load but if there is maintainer they must
> not over rule him.

Removing a maintained part of FFmpeg might be the extreme example - I think the
listed maintainer always deserves to be part of the voting committee whenever
the decision in question directly affects the maintainer's part of FFmpeg.


> There should be restriction on voting committee to remove some part of FFMpeg,
> or I fear that bad voting committee can tear this project apart.
> 
> There may be one more scenario like there is committee of  20 people where 11
> voted on X way and 9 voted on Y way. and at end of day 9 voter forked ffmpeg and
> made there own project.
> So I would put one more restriction here that its not about what majority wants 
> X way or Y way there should be what reasons are given to follow X way or Y way.
> and confirmation that everyone understand pros and cons of particular way. No
> valid reason given against anyones wills other then majority voter should be
> avoided at any cost or we may loose developer.

I think that having a list of decisions deserving more than simple majority
might be overkill. At the end there will always be developers leaving for not
being happy about democratic decisions.

-Thilo