Hi, On Sat, Sep 12, 2015 at 4:21 AM, Yayoi Ukai <yayoi.u...@gmail.com> wrote:
> On Thu, Sep 10, 2015 at 10:46 AM, Michael Niedermayer <michae...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
