[FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with GitHub

[Nicolas George]

Paul Buxton (12021-08-12):
> From the point of view of someone who is currently developing a filter for
> ffmpeg and will be submitting a patch to the list for the first time, I
> think this is a great idea.Whilst following simple instructions to prepare
> and submit a patch should't be outside the ability of anyone who is capable
> of contributing. Using something like github allows a more automated
> workflow that can make the process smoother and even make lives easier for
> the maintainers as it is possible for the automations to catch issues
> before they get sent on to you.

Have you wondered why these periodical threads "we/you should make
FFmpeg more attractive" usually end up a discussion between disgruntled
newbies congratulating each other for their great ideas, with only the
occasional bored experienced developer stepping in?


TL;DR: Do not make posting patches on the mailing-list easier, make a
two-tiered system where beginners learn to make high-quality patches
before submitting them for review to the experienced developers.


You all seem to assume that attracting more developers is always a good
thing.

It is if it attracts promising developers, i.e. if it widens the
horizon.

That requires probably making sure the project is seen as alive and
progressing, with governance and direction, withe people capable of
making decisions on the direction of the progress, to accept or clearly
reject original ideas coming from nobodies. Right now, the project is
adrift, changes are being "accepted" more based on who happens to have
commit rights and neglects to seek approval from peers.

But more developers is not a good thing if it is done by lowering the
bar, because the more developers will be mediocre and as such a drain on
the time of core developers.

Patches from newbies will require review. The more clueless the newbies,
the more time required turn the patch into something acceptable. And of
course, patches will be discusses by core developers on the mailing
list, so people who do not bother to optimize their mails for reading
(see https://ffmpeg.org/pipermail/ffmpeg-devel/2021-August/283402.html )
are especially obnoxious.

I will gladly concede that the entry bar of subscribing to a
mailing-list is hardly adequate to achieve the objective of winnowing
mediocre candidates. But if your proposal is to just discard the bar,
you are entirely missing the point.

I wonder if a scheme where clueless developers are rejected in a polite
but concise and semi-final standardized way:

# Thanks for your proposal. Your input will not be considered because it
# contains obvious and easily avoided flaws:
# [x] not following mailing-list rules;
# [x] not following coding style conventions;
# [ ] mangled or misformatted patch;
# [ ] problems of code hygiene;
# [x] bad commit message.
# For details, see <http://ffmpeg.org/doc/newbies/>. If you can fix
# these flaws by yourself, you may become a valued contributor to this
# project. If you cannot, then please go grok some PHP or something.

Then feel free to set-up a Discourse or Discord or whatever kids use
these days to help each other pass the bar. As long as what we get on
the mailing-list are patches that are already in good shape for review,
it is all good.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20210812/1dcaa7c9/attachment.sig>