Re: [arch-dev-public] Improving overall experience for contributors
[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. -- Gaetan
Re: [arch-dev-public] Improving overall experience for contributors
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 pgpTp9PNrO3tF.pgp Description: PGP signature
Re: [arch-dev-public] Improving overall experience for contributors
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. [1] https://git.archlinux.org/ signature.asc Description: PGP signature
Re: [arch-dev-public] Improving overall experience for contributors
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?
Re: [arch-dev-public] Improving overall experience for contributors
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
Re: [arch-dev-public] Improving overall experience for contributors
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. -- Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-dev-public] Improving overall experience for contributors
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
