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
signature.asc
Description: PGP signature
_______________________________________________ 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".
