[arch-dev-public] Improving overall experience for contributors

[Lukas Fleischer]

On Tue, 23 May 2017 at 22:23:51, Bartłomiej Piotrowski wrote:
> One of the problems I keep hearing about is that there is no clear place
> where potential contributors could start. Sure, some things seem obvious
> to us: take care of some wiki article or adopt orphan AUR packages. It
> isn't actually that easy. Not everyone is interested in editing or
> maintaining random packages, and while there is plenty to do, how
> someone new could know it? We could use help not only with existing
> projects like archweb, pyalpm or namcap, but also with development of
> new code (for example a maintainable rebuild automation) and
> infrastructure side (which is in fact too generic term that could be
> better described). I am totally in love with What can I do for
> Mozilla?[1] which is open source, so why not steal this wonderful idea?
> But it also means we need a way to communicate with people interested in
> helping us: at least an IRC channel and new mailing list.
> 

I totally agree here. It would be amazing to have more people contribute
to our side projects. For example, aurweb could use some more
programmers interested in Python or PHP, and it certainly isn't the
project that needs additional contributors the most.

Setting up something like "What can I do for Mozilla?" or at least some
good up-to-date Wiki page certainly is a good idea. It should be linked
from some prominent place and should also be easily googleable. Now we
only need to find some contributors to do all that... :)

> Another thing that I heard in last few months isthat it is actually hard
> for potential TU candidates to find a sponsor. While I believe it is
> perfectly fine to e-mail few potential sponsors to ask for opinion,
> throwing random messages at people doesn't sound really appealing.
> In my humble opinion, we should rethink the way we recruit people
> and probably introduce fine-grained permissions to dbscripts that
> would allow to limit new maintainers to limited set of packages.  We
> should also lower our expectations towards candidates. At least once
> we rejected one for some stupid reason (no fingerpointing here, I'm
> not saint either), leaving packages they wanted to adopt virtually
> orphan. It's better to help amn inexperienced packager gain
> experience than voting no, really; to be brutally honest, quite a
> lot of packaging work we are handling doesn't have much in common with
> rocket science.
> 

I used to share the same thoughts. The process is a bit cumbersome and
not well-documented. However, from a present-day perspective, I think
that requiring applicants to be proactive is a good thing. Having
somebody with the courage and endurance to go through the application
process is a first indication that this person is self-reliant yet able
to communicate. It may not be one of the main criteria based one which
we should decide whether or not to add somebody to our team but removing
that aspect also does not seem like a good idea to me.

In contrast, something I think we should improve on is working with
one-time contributors. It occurs quite often that users post patches on
the bug tracker or some mailing list and then these patches start to
bit-rot. This might be easier once we switch to Git for the package
repositories and might also be related to the last thing you mentioned
below...

> I also wanted to touch mailing lists vs GitHub vs Gitlab topic but we
> will tackle it another time.
> 

I personally prefer patch submission and discussion via mailing lists to
pull requests and web interfaces. As a maintainer of aurweb, I would
consider it a setback to move to something that makes maintenance work
more cumbersome for me. However, if it turns out to improve either the
quality or quantity of patches (without reducing the other), I am fine
with switching.

Regards,
Lukas