Re: Community renewal and project obsolescence
>>>>> "Daniel" == Daniel Gröber <dxld@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.
Reply to: