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

[Giancarlo Razzolini]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 870 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20170523/2605a746/attachment.asc>