[FFmpeg-devel] Voting committee

[Nicolas George]

Le decadi 30 fructidor, an CCXXIII, anshul a écrit :
> 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.
> 
> 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.

Thilo's reply already gives the gist of what I wanted to reply.

The current list of maintainers should probably be used to help establish
the "second stage" list of voters.

After that... Well, there is a basic assumption behind the rule set that I
propose: that the majority of developers mean well for the project, and
would vote accordingly.

If most voters agree on the principle "feature X has an active maintainer =>
it should not be removed", then they would vote NO to removing it, and there
is no need to make it a formal rule.

> 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.

You may notice that this is already in the rule set that I proposed:

# The reply must include, in its first sentence, an unambiguous statement of
# the nature of the reply and a terse rationale for it.

It is only for the "clear consensus" case, because I consider the "formal
vote" case to be a last resort: at this point, all arguments have been
discussed to death already.

To summarize it another way: having a voting process should not be an excuse
to vote like an egoistical asshole.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150916/b3759a01/attachment.sig>