Improving overall experience for contributors

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Improving overall experience for contributors

Bartłomiej Piotrowski-3
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

[1] https://whatcanidoformozilla.org/


signature.asc (537 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Improving overall experience for contributors

Gaetan Bisson-2
[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.

--
Gaetan

signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Improving overall experience for contributors

Giancarlo Razzolini-2
In reply to this post by Bartłomiej Piotrowski-3
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

attachment0 (887 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Improving overall experience for contributors

Jerome Leclanche-2
On Wed, May 24, 2017 at 2:19 AM, Giancarlo Razzolini
<[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Improving overall experience for contributors

Lukas Fleischer-2
In reply to this post by Bartłomiej Piotrowski-3
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
Reply | Threaded
Open this post in threaded view
|

Re: Improving overall experience for contributors

Jelle van der Waa-2
In reply to this post by Gaetan Bisson-2
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 (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Improving overall experience for contributors

Bartłomiej Piotrowski-3
In reply to this post by Gaetan Bisson-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Improving overall experience for contributors

Antonio Rojas-2
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?
Reply | Threaded
Open this post in threaded view
|

Re: Improving overall experience for contributors

Christian Rebischke-2
In reply to this post by Jelle van der Waa-2
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 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Improving overall experience for contributors

Giancarlo Razzolini-2
In reply to this post by Lukas Fleischer-2
>
> 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

attachment0 (887 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Improving overall experience for contributors

Gaetan Bisson-2
In reply to this post by Bartłomiej Piotrowski-3
[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