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
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
