Lack of replies
Antonio Russo wrote: > As someone who would like to participate more in the development of Debian, > 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). For salsa and BTS, one reason for lack of reply can be that the maintainer is never notified. I get surprised sometimes that salsa has merge requests waiting for me. I suspect that either the email notification is broken or off by default and I never saw instructions to enable it. In the case of the BTS: it used to email me but that broke a couple years ago and apparently it is hard to fix. So currently a class of us don't get email from any bug reports. My suggestion, therefore, is: if the patch is important to you, do also CC directly the maintainer address. -Steve signature.asc Description: This is a digitally signed message part.
Re: Community renewal and project obsolescence
> "Daniel" == Daniel Gröber 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.
Re: Community renewal and project obsolescence
On Fri, Dec 29, 2023 at 08:48:28AM -0800, Antonio Russo wrote: > As someone who would like to participate more in the development of Debian, > 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). There are multiple reasons for that, some common to all of these, some specific to some contribution types, but all ultimately boil down to other people being volunteers. There is no direct way to improve this beyond magically increasing the total amount of time spent by maintainers on Debian work. Some processes or tools could be improved but I'm not sure how much would that help. > If there were a single thing that could be done, in my mind it would be to > have someone > make sure that contributions do not go entirely ignored. Even just telling > someone "hey, > none of the stuff you're submitting is really good enough for Debian" would > be helpful > because they could either work on improving, or stop trying to contribute. There is no polite way to tell that, but also it's not a big problem for the project if somebody who submits very bad RFSes gets those RFSes ignored instead of being told to stop waiting for feedback on them. Giving constructive feedback, on the other hand, can be very time-draining, especially to first-time contributors submitting poor quality things. This is not even specific to Debian but applies to any open source maintainer work.
Re: Community renewal and project obsolescence
On Fri, Dec 29, 2023 at 06:49:47PM +0100, Daniel Gröber 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). > > This is also my experience. > > A related question I've been pondering: did salsa make this worse for new > contributors because some maintainers (seem to) ignore issues/MRs there? Maybe, but also salsa MRs being ignored by default was an intentional decision AFAIK, both a technical decision of not notifying maintainers about created MRs and a policy decision of the BTS being the only officially promoted way to contact maintainers and submit patches. I have no idea if people are actually told that before they submit MRs. > I figure for the many people coming from GH style platforms nowerdays being > ignored on salsa would be a major discouragment to contributing. Well, salsa didn't make this worse, it just added something that can be ignored. > > If there were a single thing that could be done, in my mind it would be > > to have someone make sure that contributions do not go entirely ignored. > > I've been thinking along those lines too. Perhaps we just need an > aggregator that flags mails/comments/other contributions by new people that > are being ignored. You'll still need people to provide feedback.
Re: Community renewal and project obsolescence
Hi, 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). This is also my experience. A related question I've been pondering: did salsa make this worse for new contributors because some maintainers (seem to) ignore issues/MRs there? I figure for the many people coming from GH style platforms nowerdays being ignored on salsa would be a major discouragment to contributing. > If there were a single thing that could be done, in my mind it would be > to have someone make sure that contributions do not go entirely ignored. I've been thinking along those lines too. Perhaps we just need an aggregator that flags mails/comments/other contributions by new people that are being ignored. I've been meaning to do something like that for the d-mentors list but perhaps we need to think bigger. --Daniel signature.asc Description: PGP signature
Re: Aw: Re: Community renewal and project obsolescence
On 2023-12-29 04:14, Steffen Möller wrote: > What hypothese do we have on what influences the number of active individuals? > > Positive factors > * Location of DebConf (with many or not so many devs affording to attend) > * Popular platforms like the Raspberry Pi working with Debian derivative > * Debian packaging teams on salsa > * self-education > * Impression the DD status makes on outsiders/your next employer > * Pleasant interactions on mailing lists with current or past team members > * Team building with other DDs on projects of interest > > Negative factors > * Advent of homebrew+conda > * Containers > * Increasing workloads as one ages and does not give packages up > * Work-life-balance > * Migrating to upstream > * Delay between what upstream releases and what is available in our distro > * Unpleasant interactions on mailing lists with current or past team members > > Do you have a better list? > I keep thinking about what the last significant change in Debian may have > been - to mind came salsa.debian.org. Do I miss anything? > And I think the change I would like to see the most is a variant of > brew/salsa for Debian, preferably in some mostly automated way, so we have > some way to install the very latest with Debian all the time. > > Best, > Steffen As someone who would like to participate more in the development of Debian, 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). If something as low stakes as looking at a patch to fix something broken can be ignored so easily, the idea of asking someone to sign a PGP key or vouch for me in the NM process seem entirely out of the question. I've assumed this is due to current DDs being overburdened. If there were a single thing that could be done, in my mind it would be to have someone make sure that contributions do not go entirely ignored. Even just telling someone "hey, none of the stuff you're submitting is really good enough for Debian" would be helpful because they could either work on improving, or stop trying to contribute. Antonio OpenPGP_0xB01C53D5DED4A4EE.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Aw: Re: Community renewal and project obsolescence
> Gesendet: Donnerstag, 28. Dezember 2023 um 20:02 Uhr > Von: "Mo Zhou" > An: debian-project@lists.debian.org > Betreff: Re: Community renewal and project obsolescence > > On 12/28/23 10:34, Rafael Laboissière wrote: > > > * M. Zhou [2023-12-27 19:00]: > > > > Thanks for the code and the figure. Indeed, the trend is confirmed by > > fitting a linear model count ~ year to the new members list. The > > coefficient is -1.39 member/year, which is significantly different > > from zero (F[1,22] = 11.8, p < 0.01). Even when we take out the data > > from year 2001, that could be interpreted as an outlier, the trend is > > still siginificant, with a drop of 0.98 member/year (F[1,21] = 8.48, p > > < 0.01). > > I thought about to use some models for population statistics, so we can > get the data about DD birth rate and DD retire/leave rate, as well as a > prediction. But since the descendants of DDs are not naturally new DDs, > the typical population models are not likely going to work well. The > birth of DD is more likely mutation, sort of. > > Anyway, we do not need sophisticated math models to draw the conclusion > that Debian is an aging community. And yet, we don't seem to have a good > way to reshape the curve using Debian's funds. -- this is one of the key > problems behind the data. What hypothese do we have on what influences the number of active individuals? Positive factors * Location of DebConf (with many or not so many devs affording to attend) * Popular platforms like the Raspberry Pi working with Debian derivative * Debian packaging teams on salsa * self-education * Impression the DD status makes on outsiders/your next employer * Pleasant interactions on mailing lists with current or past team members * Team building with other DDs on projects of interest Negative factors * Advent of homebrew+conda * Containers * Increasing workloads as one ages and does not give packages up * Work-life-balance * Migrating to upstream * Delay between what upstream releases and what is available in our distro * Unpleasant interactions on mailing lists with current or past team members Do you have a better list? I keep thinking about what the last significant change in Debian may have been - to mind came salsa.debian.org. Do I miss anything? And I think the change I would like to see the most is a variant of brew/salsa for Debian, preferably in some mostly automated way, so we have some way to install the very latest with Debian all the time. Best, Steffen
