>>>>> "Daniel" == Daniel Gröber <d...@darkboxed.org> writes:
Daniel> Hi, Daniel> On Fri, Dec 29, 2023 at 08:48:28AM -0800, Antonio Russo wrote: >> [...] my personal experience is that making contributions is like >> dropping a message in a bottle into the sea. It feels like a >> complete crap-shot whether I'll even receive a comment on any >> code contribution (including debian-devel RFS, salsa MR, or BTS >> patch). Daniel> A related question I've been pondering: did salsa make this Daniel> worse for new contributors because some maintainers (seem Daniel> to) ignore issues/MRs there? I think so. Especially for group-maintained packages, it is very easy to get into a situation where no one is actually notified for a MR on a given repository. More generally, as a maintainer, when I find I'm ignoring someone it's typically because: * The idea has some merit; if it was complete junk I could close it as wontfix or invalid or whatever. * But it requires significant effort from me to get to a place where it lands. * And I don't care that much. Examples include ideas where there's significant review that would be needed; ideas where there's some rework needed; or especially ideas where it's important to consider the implications between the new idea and some part of the system that neither I nor the submitter understands well. Another common challenge is an idea that disturbs some part of something that's been mostly chugging along fine for years, but that has entirely inadequate test coverage to know whether this new code will break things. I feel bad saying "that's great, but please write a test suite to cover your contribution as well as a significant chunk of the package you are touching," but can rarely work up the interest in doing that test suite myself if I don't care much about the enhancement/fix. Another challenge is when some idea involves significant coordination work. For example there are a few pam bugs that boil tdown to pam-auth-update isn't quite fine grain enough to capture some distinctions that matter. Proposing a new design, and moving that across the archive would be a lot of work. Or for example there's a merge request/bug on pam to enable group write umask by default with usergroups. Which apparently there was a consensus to do way back in the day. I'm concerned that consensus predates modern thinking about being restrictive in write permissions, and something's probably going to break, but on the other hand Ubuntu does it, and it's probably going to enable some valuable use cases. Deciding how to act on something like that is hard. And yet I completely get your side of things. If you try to contribute and aren't welcomed, it totally destroys motivation.