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. > * The authors of proposals should try to amend proposals based on > raised issues & reservations and restart the process if changes > where made. There could be a maximum number of such restarts after > which only vetos would block > > If this doesnt work due to too many vetos then it could be adjusted > to require 2 or more vetos to reject a proposal, but IMHO i dont think > this would be needed. Simply having ones full name in public with a > veto should result in people using the veto right wisely. > > A "unanimous consent" system also should push toward cooperation > and discussions intended to find compromises and understanding the > others. Because simply trying to be loud and push and troll are > unlikely effective means to find an agreement. also such a system, if > it works, would ensure noones oppinion or suggestion is just pushed > aside > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > There will always be a question for which you do not know the correct answer. > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
