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

[Ronald S. Bultje]

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?

Ronald