[FFmpeg-devel] [RFC] replace some static with asm_visibility or so

Diego Biurrun diego
Tue Jan 29 11:11:49 CET 2008


On Tue, Jan 29, 2008 at 12:09:46AM -0500, Rich Felker wrote:
> On Tue, Jan 29, 2008 at 05:46:31AM +0100, Michael Niedermayer wrote:
> > On Mon, Jan 28, 2008 at 11:22:04PM -0500, Rich Felker wrote:
> > > On Tue, Jan 29, 2008 at 04:46:31AM +0100, Michael Niedermayer wrote:
> > > > > > * not following democratic vote on mplayer-dev-eng about uotis account
> > > > > 
> > > > > Democracy is more than just voting, you need a constitution.  You could
> > > > > say that the policy document is such a thing, but it says nothing about
> > > > > voting or when an account should or will be revoked.
> > > > 
> > > > You dont need a constitution, a constitution can help clarify some things
> > > > but its not strictly essential. Any group of N people can just vote about
> > > > something without writing a constitution first.
> > > 
> > > I disagree strongly with this claim. Without a constitution specifying
> > > how the voting works, voting cannot be meaningful unless there's
> > > always a clear dichotomy between choices and everyone agrees on who
> > > gets to vote, etc. Whenever there are more than 2 choices, voting is a
> > > highly nontrivial matter, and usually when there are only 2 choices
> > > it's because the person calling the vote framed the question in a
> > > biased way by setting up false dichotomies... (I'm talking about
> > > voting in general not ffmpeg/mplayer history...)
> > 
> > for us:
> > who= all developers
> > how= well just use debians system if there are more than 2 choices
> > 
> > also, off topic but IMHO framed voting is better than no voting
> > though yes i fully agree there are some cases where it really fails
> > like if you can vote between 2 political parties both  having a similarly 
> > stupid agenda
> 
> keep in mind that even proposing a particular yes/no topic for vote
> (like kicking out uau) at an apt moment is a form of framing in
> itself. the same sort of thing happens in politics all the time. a
> politician will get screwed over one scandal when hundreds of others
> walk free after doing much worse things, just because a particular
> person in the media or an opposing political faction set them up for
> it.
> 
> > > These sorts of issues, among other things, are why consensus process
> > > is generally more respected than 'plain democratic vote' among folks
> > > working in the social justice field.
> > 
> > the problem with "consensus" is that you do not solve any of the inherit
> > problems of a democratic vote. Instead you add more problems.
> > 
> > consensus amongth whom vs. who votes
> > 
> > consensus for > 2 options vs. vote for >2
> > If you listen carefully, then with consensus stuff everyone just keeps
> > trying an option until a large enough majority is reached, and in the
> > process people get over time more willing to choose options they consider
> > bad
> > I would not consider such an ad hoc process optimal, a clear system
> > like debians is much more resistant to social manipulation. People
> > being very good at arguing, people who happen to be not around while
> > the consensus is formed. A vote can easily collect data from people
> > over a month not randomizing based on todays available people
> 
> consensus is more about recognizing everyone's requirements and
> working on a solution that doesn't seriously step on anyone's, as
> opposed to just seeking a majority and saying "fuck the rest". success
> of course requires everyone to believe in the system to some extent,
> i.e. the participants need to want to reach a mutually acceptable
> solution (rather than just wanting to "win") and need to be willing to
> actively "step up" and "step back" according to the relative degrees
> to which each person's needs have been represented so far. it's
> obviously not very feasible for a group full of mutual hostilities,
> but for one with common goals and vision but different ideas for how
> to best reach them, it can be a very valuable tool.

Well spoken (both paragraphs).

Diego




More information about the ffmpeg-devel mailing list