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

[Michael Niedermayer]

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.
* 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150910/6e83b15d/attachment.sig>