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