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

[Alec Warner]

On Tue, Jul 18, 2017 at 5:40 PM, Michał Górny <mgorny@g.o> 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@×××.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.

When I read your comments I see some issues being raised:

How do you recruit new people to join a team that already has "a lot of
people" working on problems?
How do you set up incentives to entice existing team members to contribute
more?
Why do people who do nothing stick around?

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.

I suspect this type of thing would be tough to deploy in Gentoo as a whole
(because people enjoy their particular way of managing their project and
dislike change) but its one idea to try to manage staffing of teams via
different metrics. It also requires a manager; someone who cares about the
bug metrics, to actually look at the metrics and manage the backlog. Given
existing team managers also do not look at their staffing numbers (e.g. the
staffing needs page is poorly maintained) I'm not convinced adopting a
different solution will necessarily have good effects. In the end someone
inside of Gentoo needs to care about things like sourcing, staffing, and
recruiting. Recruiters certainly care about the latter; but I'm not sure
the former has any particular owner.

I'm not sure how we can incentivize developers to contribute more. One
thing we did in the past to recognize developers was to interview them in
the GMN. I had considered doing a similar thing like "top developer of the
month" or something to reward contributions in some way. I had also
considered taking Google's "peer bonus" concept and trying to reward
exceptional contributions with Foundation money (via some kind of voting
process or having the council give out awards or something.) However that
had numerous legal implications (and tax implications for the receiver) and
so it was nixed.

For people who just 'hang around' I think Gentoo as a whole could offer
clearer developer emeritus benefits that might convince people who are not
doing a whole lot to actually accept retirement / emeritus status. A lot of
people stick around to be 'in the group' and to keep their email. As long
as they remain in one project they can stick around! We have the
undertakers project and they do great work; but it can still take many
months / years to actually retire someone determined to stick around but
not contributing anything meaningful.

-A


> --
> Best regards,
> Michał Górny
>