> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of
> Marth64

> The project is hard to work with or seemingly "hostile, non-
> welcoming"
> because we are using ancient workflows that aren't conducive to new
> innovation,
> or iterative development.

The workflow and tooling is archaic, yet it's just an entry barrier, but it's 
not what causes the "hostile, non-welcoming" appearance.

> The project already has technical leaders.

Not in a way that they are able to properly execute real leadership. 

As a contributor, I'm expecting my contributions to:

- Not be ignored
- Receive one of these three responses:
  1. OK (and get merged in a timely manner)
  2. No (for whichever reason)
  3. Ok but needs changes

Case 3 is the crucial one and should include

- An indication that the aim and direction of the contribution is
  generally acceptable

- Guidance on which changes should be made to become accepted,
  most importantly not only pointing at what is wrong but how 
  it should be done instead to become acceptable

This is what leadership means in a software project and anybody who isn't able 
to provide this kind of guidance cannot fulfill the role of a technical leader. 

There are always many ways to do certain things in software development, and it 
cannot be expected from contributors to provide countless different 
implementations until nobody will object anymore. This is software development, 
not a quiz show.

Objections on details which are lacking suggestion for how to change it, should 
be considered invalid in general. If somebody wants to have a say in something, 
this cannot just mean the right to voice an objection, it also has to include 
the responsibility and obligation to advise in a constructive way.

And that's the ill aspect of what those "democratization" ideas are going for: 
Most people appear to be longing for having rights - but without taking 
responsibility, and the primary understanding of those rights is the ability of 
objecting to any decision.
All this would just further grow the awful culture of nay-saying.

This is just the opposite of what the project needs. It needs few people who 
are in charge, who take responsibility and who are saying yes to everything 
that brings the project forward.

sw 


_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Reply via email to