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.

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