On Sat, Jun 14, 2025 at 07:09:59PM +0200, IOhannes m zmölnig wrote: > > > >I think the other reason why these discussions are a bit frustrating > >is that there seems to be an implicit assumptions that all > >contributions from newcomers *must* be good, > > dunno. > I think the implicit assumption is that "new *contributors* are > good" (which I can relate to), not necessarily that their > contributions are of outstanding quality.
The obvious counter example here is Jia Tan[1][2]. Another more recent example is the "X11Libre" developer who had to get ejected from Freedesk.org after contributing a huge number of questionable commits[3]. [1] https://cyberscoop.com/open-source-security-trust-xz-utils/ [2] https://www.wired.com/story/jia-tan-xz-backdoor/ [3] https://www.phoronix.com/news/X.Org-Server-Lots-Of-Reverts And there have been some over-eager contributors in the Linux Kernel community that were actively bad enough that maintainers just started ignoring them. The worst ones were the ones that tried to "help" other newcomers by giving (bad) advice and code review, to the point where some senior maintainers had to tell other contributors, "feel free to ignore anything coming from this particular person". (So just as not all contributors are not necessarily good, not all code reivews are necessarily constructive, either...) I do agree that in the ideal world, sure, potential contributors should get some kind of response. The question is whether shaming voluinteers by demanding that they provide labor to respond to contributors is either (a) ethical, or (b) productive. I don't see it as much different than demanding that an open source programmer develop some feature, or investigate some bug fix, by some entitled user or corporation expecting that free software is the same as free support or free work. If some debian developer wants to make it to be their special mission to help out new contributors, and be that ombudsperson to review patches, and tell them how "no really, you need to follow the upstream's documented requirements for code submissions[4]", or "gee, it appears that your code doesn't even build; I suggest you try to test-compile your patch and run it through the project's regtression suite", or, "Ah, your patch seems to allow shell scripts from the network to be blindly run on the target system", great! [4] https://www.kernel.org/doc/html/latest/process/submitting-patches.html It's when package mainatiners are told that somehow they are "less than" for not dealing with new contributions quickly enough, especially when they send pull requests to places which they don't follow, that I'd suggest that perhaps we need to tell those people issuing these sorts of demands that there needs to be the organizational equivalent of "patches gratefully accepted". If you want a new feature; code it yourself. If you think new contributors should get more attention, perhaps you should be part of the solution instead of demanding more work from volunteers. I'll also note that most of the time maintainers are well motivated to try to recuit people to help out; many hands make light work, and all that. But also needs to be understood that any time you spend a lot of time helping a new contributor, you are taking a risk that the effort you put into helping that new contributor has a positive return on investment. If too many contributors end up having a negative ROI, and maintainers are shamed into helping those newbies out regardless, that can be a recipe for maintainer burnout, or another Jia Tan episode. Cheers, - Ted
