[FFmpeg-devel] [PATCH] doc/developer.texi: Add a code of conduct

Rostislav Pehlivanov atomnuker at gmail.com
Wed May 25 19:19:53 CEST 2016


On 23 May 2016 at 17:26, Michael Niedermayer <michael at niedermayer.cc> wrote:

> On Sat, May 21, 2016 at 05:28:09PM -0400, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Sat, May 21, 2016 at 11:32 AM, James Almer <jamrial at gmail.com> wrote:
> >
> > > On 5/18/2016 3:40 PM, Michael Niedermayer wrote:
> > > > Signed-off-by: Michael Niedermayer <michael at niedermayer.cc>
> > > > ---
> > > >  doc/developer.texi |   29 +++++++++++++++++++++++++++++
> > > >  1 file changed, 29 insertions(+)
> > > >
> > > > diff --git a/doc/developer.texi b/doc/developer.texi
> > > > index 6db93ce..4d3a7ae 100644
> > > > --- a/doc/developer.texi
> > > > +++ b/doc/developer.texi
> > > > @@ -403,6 +403,35 @@ finding a new maintainer and also don't forget
> to
> > > update the @file{MAINTAINERS}
> > > >
> > > >  We think our rules are not too hard. If you have comments, contact
> us.
> > > >
> > > > + at section Code of conduct
> > > > +
> > > > +Be friendly and respectful towards others and third parties.
> > > > +Treat others the way you yourself want to be treated.
> > > > +
> > > > +Be considerate. Not everyone shares the same viewpoint and
> priorities
> > > as you do.
> > > > +Different opinions and interpretations help the project.
> > > > +Looking at issues from a different perspective assists development.
> > > > +
> > > > +Do not assume malice for things that can be attributed to
> incompetence.
> > > Even if
> > > > +it is malice, it's rarely good to start with that as initial
> assumption.
> > > > +
> > > > +Stay friendly even if someone acts contrarily. Everyone has a bad
> day
> > > > +once in a while.
> > > > +If you yourself have a bad day or are angry then try to take a break
> > > and reply
> > > > +once you are calm and without anger if you have to.
> > > > +
> > > > +Try to help other team members and cooperate if you can.
> > > > +
> > > > +The goal of software development is to create technical excellence,
> not
> > > for any
> > > > +individual to be better and "win" against the others. Large software
> > > projects
> > > > +are only possible and successful through teamwork.
> > > > +
> > > > +If someone struggles do not put them down. Give them a helping hand
> > > > +instead and point them in the right direction.
> > > > +
> > > > +Finally, keep in mind the immortal words of Bill and Ted,
> > > > +"Be excellent to each other."
> > > > +
> > > >  @anchor{Submitting patches}
> > > >  @section Submitting patches
> > >
> > > I agree with this. It can and should be improved/extended over time,
> but
> > > it's a good
> > > start.
> >
> >
> > +1.
> >
> > Constructive criticism for next version: I agree with most people that we
> > need a conflict resolution clause in here. We don't need to be as
> specific
> > as VLC in terms of how to punish misconduct, although I think it would be
> > good to have, but at the very least we need to document how it will be
> > managed and who's in charge of managing that. Right now, if people
> violate
> > the CoC, w'll throw our hands in the air and nobody knows what to do
> next...
>
> we first try to politely point it out to people that their tone is
> insulting/disrepectfull or whatever.
> has happened recently, and worked in stoping it
> i would count that as a success
>
> But lets assume someone doesnt stop or keeps restarting
>
> if we really end up needing to, and i hope we wont then in the case
> of the mailinglists, the mailinglist admins could take care of it like
> they do with other unwanted content
>
> ATM the mailinglist admins are lou logan and compn
> The critical factor is of course that they are neutral (no history
> of taking sides in conflicts) which i belive applies to both.
> And that whatever they do, they do it consistently,
> same offense ->  treated similar
> and some attempt is made to do the minimal and effective thing
> for example if talking with people makes them
> stop thats better than baning them for some period ...
>
> And i belive being told by the ML admin to stop and not do something
> again has some weight ...
>
>
I absolutely agree. I think a punishment clause is basically going to cause
far more harm than it will ever do good by giving bad people weapons. I
think we're civilized enough to know when to stop, and if not, the ML
admins will make us stop. But punishing people for going a step over the
line (especially if they realize that a bit too late, because you know,
everyone has bad days) is something I wouldn't want to see. The world of
multimedia is one that is full of disagreement, so discouraging
disagreements because there's always a danger of being accused of a
"misconduct" is going to result in a far worse project since you wouldn't'
be able to remove or add controversial code without offending someone,
getting into an argument and one of the two or both of you being cast out
as "troublemakers".
Chances are if it ever comes to that the majority of developers will agree
that person is being an ass and just take him out of the project by
ignoring him, not responding to his emails, etc.

So I'm against modifying the CoC to be any more explicit than it already
is, since you know, most of the time the word "please" is powerful enough,
and when it isn't, temporary ban on the judgement of the ML admins would
be. No need to go ahead and bring politics made to ruin everyone else's
time in.


More information about the ffmpeg-devel mailing list