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
pgpCxaNmA3Z11.pgp
Description: PGP signature
