[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How to motivate contributors to work on QA



Hey Christian

On 2021/03/23 11:42, Christian Kastner wrote:
> However, looking at this from the other side of the argument, I still
> believe that relying on pure volunteer work has significant downsides to
> the quality of our distribution, downsides that IMO could or should
> easily be avoided by a project that receives non-negligible amounts of
> donations (some of which, I assume, were given precisely to maintain and
> improve the its quality).
> 
> I'd like to give you two concrete, specific examples where I think that
> pure volunteer work meets its limits, bothr related to QA work. Insofar
> as you agree with me on these examples, I'm interested in hearing your
> suggestions one what you, as DPL, could/would do to address these examples.
> 
> [I'm clearly biased towards financially motivating developers, because
> that's what I believe some of the donations are intended for. At least,
> that's my motivation when I donate to other FOSS projects. But I'm
> interested in hearing any form of solution.]
> 
> 
> Example #1: Orphaned/RFA'd packages
> ~~~~~~~~~~~
> Orphaned packages are packages that, by definition, no one is interested
> in maintaining. There are no volunteers willing to commit to them.
> 
> However, some of these packages are important to the Debian ecosystem.
> For example, schroot is a key package for our infrastructure and for
> many contributors, yet it's been orphaned since 2018. Other orphaned
> packages are less visible directly, but may have dozens of affected
> reverse dependencies.
> 
> I think it's fair to say that RFA'd packages are closely related to this.
> 
> 
> Example 2#: Undermaintained packages, especially in stable
> ~~~~~~~~~~~
> 
> This is something that every contributor, including me, can probably
> relate to.
> 
> There are some packages that have a maintainer, but that maintainer does
> not have sufficient time to devote to the package, sometimes to the
> point where filing a bug is pointless.
> 
> Some of these issues can be fixed by NMU. Many aren't. For example, I
> think the share of non-DSA security issues and important bugs that can
> be fixed in stable could be much larger, but that's quite a bit of extra
> work compared to fixing something in unstable.
> 
> [This is *not* intended to be a shaming or something. I myself have been
> in the position where for personal reasons, I simply had zero time for
> Debian, and didn't even read my Debian account mail for more than a year.]
> 
> Addressing these two examples would clearly make Debian an even better
> product. And I say this not as a contributor, but as a user who is
> frequently affected by the above two examples.
> 
> My question to you is: If you share my view that the above two examples
> are significant problems, what could you, as DPL, concretely do to
> address them?

I mostly share your views, which doesn't leave too much for me to write :)

I think Raphaël's Freexian initiatives will help address the two points
you mention. I also think it would be ideal for either Freexian to
register an additional non-profit to handle these kinds of
funds/projects, or even for Debian to do so. But if you're asking for
concrete things that I would do as DPL for this over the next term,
that's really difficult right now since I don't want to make more
promises on top of my existing ones. It does seem that the support to
pay for at least some types of Debian work is larger within our
community than I have previously thought. At the same time it seems that
the demand for money for hardware is really low, it seems that our
developer needs are completely met when it comes to hardware, so maybe
we should consider spending some money for hours on some projects. I'd
be willing to initiate some framework and discussion on this on -project
in the next term, because we tend to decide things like this together in
Debian and not top-down, I think we could also have some video call
sessions in jitsi to discuss things like this and perhaps out of there
we can generate some concrete steps to take that works for everyone in
the project and our users alike.

-Jonathan


Reply to: