Hi all,
Spending some time outside the regular Arch circles, I realized that the way we "outreach" potential contributors is at least imperfect.
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.
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 also wanted to touch mailing lists vs GitHub vs Gitlab topic but we will tackle it another time.
Your thoughts? Bartłomiej
[2017-05-23 22:23:51 +0200] Bartłomiej Piotrowski:
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 opinion writing emails to strangers should be part of the application process. In my duties as packager maintainer I often find myself writing emails to various persons I've never met: other distro devs, upstream maintainers, etc. I'm sure the same goes for all of us. It's just basic communication skills.
Do we need contributors this badly that we could consider accepting applicants who are too shy to write an email to a stranger?
In my humble opinion, we should rethink the way we recruit people
I don't understand what you mean. In the past when we've had specific needs in particular areas, ad-hoc recruitment processes were devised to fill those needs. Shouldn't that be good enough? What kind of new process would you like to see implemented?
I also wanted to touch mailing lists vs GitHub vs Gitlab topic but we will tackle it another time.
Please do create a new thread as soon as possible; I just can't contain all my boiling thoughts on this... :)
Cheers.
On 05/23/17 at 10:47am, Gaetan Bisson wrote:
[2017-05-23 22:23:51 +0200] Bartłomiej Piotrowski:
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 opinion writing emails to strangers should be part of the application process. In my duties as packager maintainer I often find myself writing emails to various persons I've never met: other distro devs, upstream maintainers, etc. I'm sure the same goes for all of us. It's just basic communication skills.
Do we need contributors this badly that we could consider accepting applicants who are too shy to write an email to a stranger?
In my humble opinion, we should rethink the way we recruit people
I don't understand what you mean. In the past when we've had specific needs in particular areas, ad-hoc recruitment processes were devised to fill those needs. Shouldn't that be good enough? What kind of new process would you like to see implemented?
I disagree, I have the feeling there are a lot of ideas which would improve Arch Linux a lot. Which are now not being worked on (as far as I know). Therefore I think it would be great if there was a page where first time contributors can find projects, but this will require mentoring from Developers or TU's.
A few things I can think of which need help:
* Automate rebuilds, this is something we really need to keep rolling. * New dbscripts, moving to git, etc. * Archweb, although a lot of work is currently in progress.
On Wed, May 24, 2017 at 10:15:09AM +0200, Jelle van der Waa wrote:
I disagree, I have the feeling there are a lot of ideas which would improve Arch Linux a lot. Which are now not being worked on (as far as I know). Therefore I think it would be great if there was a page where first time contributors can find projects, but this will require mentoring from Developers or TU's.
Well, we have a projects website[1] but it's missing a section for issues, project management, todos etc. I really like the idea of an own gitlab instance. Our current project management is just too chaotic for newbies. What is missing is a simple overview over "what need to be done" or current "todos". Moreover i know that many of us like the mailinglist based patch contribution but I am pretty sure that this is an additional reason why we have such a lack on new patches.
I am pretty sure when we would have a gitlab instance or move our dev-projects to github we would have more contributions.
On 2017-05-23 22:47, Gaetan Bisson wrote:
In my opinion writing emails to strangers should be part of the application process. In my duties as packager maintainer I often find myself writing emails to various persons I've never met: other distro devs, upstream maintainers, etc. I'm sure the same goes for all of us. It's just basic communication skills.
I see a difference between writing emails on a specific topic, whether I know the person I write to or not, and spamming people "sup sponsor me" in hope of finding a sponsor. This is hardly basic. I have sponsored at least 3 TUs and it was me who initiated the sponsorship; I wouldn't be here either if I didn't know Mateusz Herych from Polish community channel. I highly doubt anyone else would sponsor me.
We are open source distribution with pretty much closed development model. It is unsustainable in the longer term. There are 413 orphan packages in our repositories (excluding i686), some of the out-of-date flags are unhandled since 2014. We updated archweb to the latest-1 LTS Django only recently, the fact that our bug tracker hasn't been pwned yet is a miracle and nothing but the wiki displays properly on smartphones. Signoffs got a second breath thanks to recruiting some testers, but there is no written procedure how to become one. We handle PKGBUILD patches in the worst way possible - we just don't. It's not even remotely hard to come up with examples.
How long do you expect people to be happy to send their changes to /dev/null before they give up? Because I already met some people that are more clever than me in every packaging related area that decided to switch to a distribution where joining is easier.
I don't understand what you mean. In the past when we've had specific needs in particular areas, ad-hoc recruitment processes were devised to fill those needs. Shouldn't that be good enough? What kind of new process would you like to see implemented?
We are at the point where we have needs in every area, and ad-hoc recruitment is silly idea in 2017, where some distributions are successfully having way smaller development team and are capable of accepting tens of one-off contributions every week (been there, done that). I do not propose to give up on sponsorship process entirely, I mean that we need a place to communicate with contributors and that also includes mentoring potential packagers.
Bartłomiej
El Wed, 24 May 2017 13:08:18 +0200, Bartłomiej Piotrowski escribió:
We are open source distribution with pretty much closed development model. It is unsustainable in the longer term. There are 413 orphan packages in our repositories (excluding i686), some of the out-of-date flags are unhandled since 2014.
And those are just the literally orphan ones. We have many more virtually orphan packages due to some dev/TUs not giving signs of life for months, even years. We do have a serious manpower issue, which I think it is starting to affect the quality of the distribution (eg. several DEs are currently unmaintained), and I don't see this getting any better with our current recruiting model. I do like the idea of having a 'trial period' of a couple of months for new contributors, under the supervision of a mentor, in which they could have access to svn but not to the repos, and perhaps move the voting to the end of this period. And yes, we need a central place to communicate our needs to potential new contributors. Perhaps we could start with a wiki page until we set up something more sophisticated?
[2017-05-24 13:08:18 +0200] Bartłomiej Piotrowski:
How long do you expect people to be happy to send their changes to /dev/null before they give up? Because I already met some people that are more clever than me in every packaging related area that decided to switch to a distribution where joining is easier.
[...]
We are at the point where we have needs in every area, and ad-hoc recruitment is silly idea in 2017, where some distributions are successfully having way smaller development team and are capable of accepting tens of one-off contributions every week (been there, done that). I do not propose to give up on sponsorship process entirely, I mean that we need a place to communicate with contributors and that also includes mentoring potential packagers.
Thanks for taking the time to explain what you meant. Now that I understand your point it seems like a good one indeed.
Cheers.
Em maio 23, 2017 17:23 Bartłomiej Piotrowski escreveu:
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 learned about Archlinux by using it's wiki long before I actually started using Arch. We have one of the most technical qualified wiki of all distros. Sure, we have some bad pages, but overall it is pretty good. The wiki seems to be the entry point for a lot of new users, nothing more straightforward than they learning how to contribute to Arch, from the wiki. I've seen a lot of people complaining about bad pages on IRC. When I tell them that they can contribute, almost all of them don't know anyone can edit our wiki, just create an account and you're good.
I like the idea of having a concise place, the wiki could point to our what can I do for arch.
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 agree partly with this one. I think the process could be simpler for applicants, but I'm against lowering the standards. If we limit them to a subset of packages we're basically creating another [community] within [community]. Maintaining packages is, for the most part, about editing text files and running some commands. But, there are bug reports, and these can't be handled by anyone. Do I open an upstream bug? Is it an user issue? Is it a packaging issue? All of the above? More often than not, these questions aren't easily answered.
What I would be inclined to accept would be that packages are, at least at first, always co-maintained by sponsor and sponsored TU. This way we can assure that new TU's can handle ll the tasks related to maintaining a package. Call it a probation period.
I also wanted to touch mailing lists vs GitHub vs Gitlab topic but we will tackle it another time.
You know my thoughts on this. But I want to ask you that you hold this until I put patchwork back in place. I resumed working on this and plan to have it back soon.
Cheers, Giancarlo Razzolini
On Wed, May 24, 2017 at 2:19 AM, Giancarlo Razzolini grazzolini@archlinux.org wrote:
What I would be inclined to accept would be that packages are, at least at first, always co-maintained by sponsor and sponsored TU. This way we can assure that new TU's can handle ll the tasks related to maintaining a package. Call it a probation period.
That sounds like it would decrease the amount of sponsoring, rather than increase the amount of applicants.
J. Leclanche
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
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.
One thing that I must point out is that having something like gitlab, doesn't preclude us from receiving patches on the mail lists. I recall setting up a gitlab hook that would create a merge request when some patch arrived on some email. Also, gitlab, and most of these tools, have API's. Hacking something should be trivial.
Cheers, Giancarlo Razzolini
On 05/23/17 at 10:23pm, Bartłomiej Piotrowski wrote:
<snip> 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 still believe we should take some initiative on thse issues. What we have so far is:
- Getting involved page, not sure where it's linked from? Only findable on the wiki. [1] Which links to a nice list of projects with an already dedicated irc channel and mailing lists. (I was not even aware of #archlinux-projects). But does anyone ever find this page? I think we should at least link it from archlinux.org.
- The mozilla idea, I'm up for it? Should we host it under whatcanidofor.archlinux.org? Note that this also requires some effort from the team's side. We should however keep our bugtracker tidy and maybe label "new contributor" tickets since this is quite crucial to get new people in. I however have also some thoughts on things which these days have no tickets, but could be worked on for example:
- revamping the Ruby guidelines. They should be as nice as the Python ones - Hardening our custom systemd services and creating bugs with patches, for example grafana has hardening applied now. [5] - Man pages for more devtools binaries.
I'm quite sure others others have such projects on their mind which are not publicly findable yet. (sogrep to devtools for example)
[1] https://wiki.archlinux.org/index.php/Getting_involved [2] https://wiki.archlinux.org/index.php/DeveloperWiki:Projects [3] https://github.com/archlinux/archweb/issues [4] https://github.com/archlinux/pyalpm/issues [5] https://git.archlinux.org/svntogit/community.git/tree/trunk/grafana.ser= vice?h=3Dpackages/grafana
arch-dev-public@lists.archlinux.org