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

[Yayoi Ukai]

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.

> * 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 at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>