[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-project
Subject:    Re: [gentoo-project] Fw: Your temporary 2 week suspension on interacting on the Gentoo Github page
From:       Rich Freeman <rich0 () gentoo ! org>
Date:       2017-05-17 15:47:57
Message-ID: CAGfcS_nfr4r45R848euOWn4fyBcKRLvPz385xb_VGty1W_q37A () mail ! gmail ! com
[Download RAW message or body]

On Wed, May 17, 2017 at 11:41 AM, William L. Thomson Jr.
<wlt-ml@o-sinc.com> wrote:
>
> Sunrise and Github PRs are not even bandaids on a gashing wound. Gentoo
> needs more developers not outside contributors! For every outside
> contributor, it requires at least 1 Gentoo dev to proxy. If not several
> for review, etc. Time is better spent recruiting said contributor.
>

There is actually a diversity of opinion on that particular topic.
Hasufell ended up leaving out of frustration because he actually
wanted the exact opposite - fewer developers and more outside
contributors.  In his view the most efficient workflow would be ALL
commits coming in via PRs with Gentoo optimized to make this the most
efficient workflow.

His argument would probably be that the current reliance on developers
tends to result in the PR workflow being overlooked and downplayed,
which makes it much harder for people to make incidental
contributions.  Rather than focusing on having more internal
developers he wanted there to be more of a focus on lowering barriers
to external contribution.  His argument would probably be that there
are a lot of potential "drive by" contributors out there who would
happily donate a pull request or two without any desire to learn much
about the Gentoo workflow or quality standards.

I'm sure he'd articulate it better than I did.

I'm not entirely convinced that we'd be flooded with PRs if we merely
made the process easier, but I think it is a very legitimate approach.
Arch's AUR might be a model of such an approach, though I confess I
don't know all the details of how it works.  You could have a layered
repository with varying levels of quality in such a model, with the
devs focusing on maintaining a smaller core and being curators for
user contributions.

Obviously any change like this would be a major one.

-- 
Rich


[prev in list] [next in list] [prev in thread] [next in thread]