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

[Ronald S. Bultje]

Hi,

On Sat, Sep 12, 2015 at 9:39 AM, Hendrik Leppkes <h.leppkes at gmail.com>
wrote:

> On Sat, Sep 12, 2015 at 3:24 PM, Michael Niedermayer <michaelni at gmx.at>
> wrote:
> > On Sat, Sep 12, 2015 at 06:50:50AM -0400, Ronald S. Bultje wrote:
> >> Hi,
> >>
> >> On Sat, Sep 12, 2015 at 4:21 AM, Yayoi Ukai <yayoi.ukai at gmail.com>
> wrote:
> >>
> >> > On Thu, Sep 10, 2015 at 10:46 AM, 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.
> >> >
> >> > So you can add a deadline for the alternate proposal. For example,
> >> > if the person who vetoed doesn't come up with an alternate proposal
> >> > within 30 days,
> >> > the original proposal must be passed.
> >>
> >>
> >> It means everyone can slow a proposal by 30 days.
> >>
> >
> >> Why do we need vetos?
> >
> > let me awnser a different question first
> > Why do we need developers/contributors?
> > to write and maintain code amongth many other reasons
> >
> > If we depend on these developers/contributors then IMO we should take
> > their oppinons and objections serious and if one of them is willing
> > to risk her/his good name to oppose a proposal in public and maybe also
> > plans to put signifiant time into creating a better compromise proposal
> > then i belive this is something that should not just be brushed away
> > easily, and especially not "quick quick" while
> > everyones minds are maybe heated about some debate
> >
> > vetos would be one way to achive this
> > iam not saying that we absolutely need vetos but i think that we
> > should not pass proposals that would cause any one developer to leave
> > the project or to make people be seriously unhappy.
> > People contribute for fun, for social reasons and because they have to
> > (like because they are paied for it)
>
> What if these "objections" make everyone else unhappy and have no fun
> anymore, because there is no good technical reason behind them, just
> personal preference (in an area where the objecting developer is not a
> maintainer)?


I want to give the specific example of the "leadership" vote that happened
just around "The Fork" in early 2011. Suddenly, out of nowhere, a bunch of
mplungarians arose that claimed (and received!) voting rights and helped
"The Fork" arise (I'm sure that was not their intention, but it was the
consequence nonetheless). Now just imagine for a second that in addition to
voting rights, we gave each developer (including mplungarians) veto rights.
This is outrageous.

To solve this problem, veto rights should, if they exist at all, be
restricted to some of the most valuable developers by whatever metric, and
be strictly limited in number (e.g. no more than 2-3 people can have veto
rights at all). Since that will cause unease for #4/#5, the obvious
alternative would be to not have vetoes at all. I can live with either of
these. And I don't need veto rights.

Ronald