Re: [gentoo-project] The problem of defunct and undermanned projects in Gentoo

[James Le Cuirot <chewi@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 5716 bytes --]

On Wed, 19 Jul 2017 13:25:31 -0400
Alec Warner <antarus@gentoo.org> wrote:

> On Tue, Jul 18, 2017 at 5:40 PM, Michał Górny <mgorny@gentoo.org> wrote:
> 
> > On wto, 2017-07-18 at 22:35 +0100, M. J. Everitt wrote:  
> > > On 18/07/17 22:23, Kent Fredric wrote:  
> > > > On Tue, 18 Jul 2017 22:12:45 +0100
> > > > "M. J. Everitt" <m.j.everitt@iee.org> wrote:
> > > >  
> > > > > I think mgorny was doing some general commit stats, and I have yet to
> > > > > compile my own, but it would be very interesting to see how many
> > > > > 'active' team members there were in any given project. I suspect the
> > > > > results could be very telling ...  
> > > >
> > > > Its not even like they're "inactive", they're just not active *in the  
> > team*.  
> > > >
> > > > For some, there's no reason for them to devaway:
> > > >
> > > > - They're on IRC
> > > > - They commit daily
> > > >
> > > > But they're on teams they seldom do things in.
> > > >
> > > > This is probably more true the more teams you're on.  
> > >
> > > Then why are you 'in' the team.. I mean, there's one thing to idle on an
> > > IRC channel, but membership does normally imply some form of
> > > contribution, no? Or is it just to make you 'look'
> > > interested/popular/part-of-the-furniture ....  
> >
> > Well, that *is* a problem. However, we are supposed to be friendly
> > and nice, and not tell other developers that they have done literally
> > nothing during the 2 years they're part of some project. That could
> > discourage them from contributing.
> >  
> 
> > You are also not supposed to try to offload yourself and distribute
> > the work to them. That's bossing around, and it discourages others from
> > actually doing anything.
> >
> > So, well, you're just supposed to smile and thank them for doing nothing
> > for the project because otherwise they could feel offended
> > and discouraged from doing anything,
> >  
> 
> I am reading a lot of frustration in your comments. I know I have been on a
> team(s) where this was the case and it was difficult to resolve. I've also
> been that person who doesn't contribute but "hangs around". It might be
> possible to think about better ways to measure progress and staffing than
> just 'people'. Its pretty clear that 'people on the team' has little
> relation to 'work done by the team'. So lets try to break that entirely?
> 
> I want to be clear that "being friendly and nice" is not necessarily the
> reason why we do not encourage the behavior you state. I suspect telling
> people they have not done anything recently doesn't necessarily encourage
> them to do stuff. Most of them have actual reasons for not contributing
> (whatever they may be) and often a simple conversation doesn't magically
> free up time for them, nor encourage them to start doing more.

...

> The most obvious thing to change is what I mentioned earlier, stop focusing
> on "number of humans" and focus on things like "backlog of work for team"
> and "velocity of team." Note that this requires ~agreement on what other
> metric to use (like bug backlog) and tools to measure the backlog and
> velocity. The GMN used to have some of these metrics for bugs.
> 
> So one idea might be to measure bug backlog and bug velocity. Teams that
> have a backlog that is not growing at a large rate, or even teams with
> positive velocity (they tend to close all of their bugs eventually or keep
> the backlog in a specific range) probably don't need operational help (they
> are correctly staffed for their workload.) Teams that have a growing
> backlog and negative velocity are understaffed (they will only get further
> and further behind.)
> 
> Note that these metrics don't necessarily care about the number of people
> on the project, or how much each person contributes. It only cares about
> the velocity of the project as a whole in relation to their bug queue. Its
> certainly not how many projects will want to work (many teams want to keep
> bugs open forever, for example.) In the past I've seen a bug "purgatory"
> type label used for this, where bugs that someone looked at and decided
> "well this is useful to keep open but isn't on the roadmap or we don't
> necessarily plan on doing it" gets pushed into the "Purgatory"; it stays in
> the bug system (open even!) but we don't count purgatory bugs as part of
> the backlog.

Definitely have to agree with this. I'm on the games team but I haven't
done all that much for that project yet. That's largely because I'm
lead of the Java team and I don't feel I'm doing enough there either.
That doesn't mean I want to leave the games team and there is plenty
I'd like to do given the time. I may still fix up the odd thing here
and there and that's certainly better than nothing.

I think there's also another angle to this, particularly when it comes
to Java. I don't think it matters how many developers we can
realistically get, the traditional approach to Java packaging stopped
being scalable years ago. That backlog is growing and we're never going
to catch it up short of taking extremely radical action. This is a hard
problem to solve. I have some ideas but once again, it needs time.
Knowing that our current course is hopeless is also very demotivating
and that just makes a bad situation even worse. I don't want to waste
time doing fruitless package bumps. When users hop onto IRC
enthusiastically asking whether they can package some shiny new thing,
it pains me to tell them that it's probably much harder than they think
and they'd also be wasting their time.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 981 bytes --]