Re: [arch-dev-public] Improving overall experience for contributors follow up

[Morten Linderud via arch-dev-public]

On Wed, Feb 06, 2019 at 04:26:03PM -0500, Eli Schwartz via arch-dev-public 
wrote:
> >   I'm quite sure others others have such projects on their mind which
> >   are not publicly findable yet. (sogrep to devtools for example)
> 
> sogrep as it currently exists on the soyuz build server depends on
> private paths to /srv/ftp
> 
> I've reimplemented it here, FWIW:
> https://github.com/eli-schwartz/dotfiles/blob/master/bin/sogrep
> 
> To go with:
> https://github.com/eli-schwartz/dotfiles/blob/master/bin/pkg-list-linked-libraries
> 
> Problem is I'm not sure either one strictly belongs in devtools.

Been meaning to write a proposal about getting a `contrib` repository that would
be staging grounds for new devtools additions, or just nice to have in general.

I believe such tools would fit in such a project and help us organize tools
loosly related to TU/Dev duties that are currently hard to share or find.

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

Re: [arch-dev-public] Improving overall experience for contributors follow up

[Eli Schwartz via arch-dev-public]

On 2/6/19 4:16 PM, Jelle van der Waa wrote:
> Hi,
> 
> 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.

We should definitely link it from archlinux.org, maybe under "Community"
in the sidebar.

However, other than that I think the wiki is a good place to keep the
list, as it is is more easily maintained as a wiki.

> - 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:

Well, perhaps moving to bugzilla would make it easier to assign extra
labels like that. :D

>   - 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)

sogrep as it currently exists on the soyuz build server depends on
private paths to /srv/ftp

I've reimplemented it here, FWIW:
https://github.com/eli-schwartz/dotfiles/blob/master/bin/sogrep

To go with:
https://github.com/eli-schwartz/dotfiles/blob/master/bin/pkg-list-linked-libraries

Problem is I'm not sure either one strictly belongs in devtools.

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

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

[Jelle van der Waa]

Hi,

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

P.S. sorry for splitting up into a new thread, but it seems replying
makes spamassasian mark my reply to the thread as spam.

-- 
Jelle van der Waa


signature.asc
Description: PGP signature

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

[Jelle van der Waa]

On 05/23/17 at 10:23pm, Bartłomiej Piotrowski wrote:
> 
> 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


signature.asc
Description: PGP signature

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

[Gaetan Bisson]

[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

[Giancarlo Razzolini]

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

[Christian Rebischke]

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

[Antonio Rojas]

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

[Bartłomiej Piotrowski]

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

[Jelle van der Waa]

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

[Lukas Fleischer]

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

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

[Jerome Leclanche]

On Wed, May 24, 2017 at 2:19 AM, Giancarlo Razzolini
 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

Re: [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

pgpCxaNmA3Z11.pgp
Description: PGP signature

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

[Gaetan Bisson]

[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
Description: PGP signature

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

[Bartłomiej Piotrowski]

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
Description: OpenPGP digital signature