[FFmpeg-devel] IRC meeting on Saturday 2015-09-12, UTC 15:00

[Michael Niedermayer]

On Thu, Sep 10, 2015 at 02:58:51PM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Thu, Sep 10, 2015 at 1:46 PM, Michael Niedermayer <michaelni at gmx.at>
> wrote:
> 
> > On Mon, Sep 07, 2015 at 11:37:47AM +0200, Stefano Sabatini wrote:
> > > Hi,
> > >
> > > I propose to have an official IRC meeting on the next Saturday, and I
> > > propose the tentative time of 15:00 UTC, but feel free to propose a
> > > different time if this can't suit you.
> > >
> > > The IRC meeting channel will be public and the log will be published
> > > at the end of the meeting.
> > >
> > > This meeting is also meant as a preparation for the real-life meeting
> > > that will be held in Paris at the next VDD
> > > (http://www.videolan.org/videolan/events/vdd15/) for the FFmpeg
> > > developers who will attend it.
> > >
> > > I propose these topics of the day (suggested by ubitux on IRC):
> > > 1. ABI compatibility policy
> >
> > > 2. general policy decision process
> >
> > heres a suggestion, maybe useful as input for discussions on
> > Saturday ...
> >
> > FFmpeg used and uses "unanimous consent" in patch reviews
> > any person could make a suggestion
> > to improve a patch and it has to be taken care of one way or another
> > before the patch is ok. This system worked quite well almost all the
> > time. So i would suggest to use the same / a similar system for
> > policy decisions
> >
> > * Everyone should be able to comment and propose options/choices
> > * There should be enough time to understand, discuss and amend
> >   proposals
> > * People should try to understand the other people and avoid strawman
> >   arguments and other non constructive discussion tactics, people/the
> >   commuity should step in if discussions become non constructive and
> >   hostile and try to get people back toward constructive discussion.
> > * People should be able to declare reservations to a proposal without
> >   blocking the proposal and as a seperate choice veto it in a blocking
> >   fashion. A veto should be public with full name of the developer,
> >   reason why it is bad for the community/project and ideally a
> >   alternative proposal. Also developers vetoing a proposal must be
> >   willing and able to work on finding an better solution.
> 
> 
> I have serious reservations about giving each developer veto rights; imho,
> we need a much higher bar than that.

> As evidence, I would like to offer the
> example of the united nations security council having only 5 members with
> veto power, and that's working out really well, right? </sarcasm> So in

I have a few problems with using the UN security council as
comparission
1. Deciding about Wars and sanctions is very different from deciding
   about the policy of a free software project. Wars and sanctions
   always harm someone, and id even claim they often help noone either.
   OTOH policy decissions in a free software project should not harm
   any of its members. If they do signifiantly harm a member then
   should they really be done? ...

2. Theres also a big similarity between the UN and a project of
   volunteers, in both cases members only are part of as long as they
   like, leaving or ignoring decissions is relatively easy.
   If you imagine the UN not having a 5 member veto right, how many
   of these 5 members would still be in the UN? how many of their
   allies ? and what meaning would the UN have or would it without
   that rule even have been formed in the first place ....
   similarly if in a group of volunteers decissions are made that
   trample over a "very strong objection / veto", do you think that
   volunteer will still contribute afterwards or just push his
   changes to his own repository on github and leave it to others
   to integrate them as they see fit?

3. the UN isnt really using a "unanimous consent" system,
   even the security council is not, as only their permanent members
   have veto power, it would make more sense to use cases where
   "unanimous consent" is actually used as comparission


> light of that, if we decide to go this route, I would humbly suggest to
> make sure our number of developers with veto power is significantly smaller
> than five. "Use it wisely" won't work, power corrupts. Let's fix it by
> design.
>
> Ronald
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

What does censorship reveal? It reveals fear. -- Julian Assange
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150911/8b9db11f/attachment.sig>