1 |
On Wed, 19 Jul 2017 13:25:31 -0400 |
2 |
Alec Warner <antarus@g.o> wrote: |
3 |
|
4 |
> On Tue, Jul 18, 2017 at 5:40 PM, Michał Górny <mgorny@g.o> wrote: |
5 |
> |
6 |
> > On wto, 2017-07-18 at 22:35 +0100, M. J. Everitt wrote: |
7 |
> > > On 18/07/17 22:23, Kent Fredric wrote: |
8 |
> > > > On Tue, 18 Jul 2017 22:12:45 +0100 |
9 |
> > > > "M. J. Everitt" <m.j.everitt@×××.org> wrote: |
10 |
> > > > |
11 |
> > > > > I think mgorny was doing some general commit stats, and I have yet to |
12 |
> > > > > compile my own, but it would be very interesting to see how many |
13 |
> > > > > 'active' team members there were in any given project. I suspect the |
14 |
> > > > > results could be very telling ... |
15 |
> > > > |
16 |
> > > > Its not even like they're "inactive", they're just not active *in the |
17 |
> > team*. |
18 |
> > > > |
19 |
> > > > For some, there's no reason for them to devaway: |
20 |
> > > > |
21 |
> > > > - They're on IRC |
22 |
> > > > - They commit daily |
23 |
> > > > |
24 |
> > > > But they're on teams they seldom do things in. |
25 |
> > > > |
26 |
> > > > This is probably more true the more teams you're on. |
27 |
> > > |
28 |
> > > Then why are you 'in' the team.. I mean, there's one thing to idle on an |
29 |
> > > IRC channel, but membership does normally imply some form of |
30 |
> > > contribution, no? Or is it just to make you 'look' |
31 |
> > > interested/popular/part-of-the-furniture .... |
32 |
> > |
33 |
> > Well, that *is* a problem. However, we are supposed to be friendly |
34 |
> > and nice, and not tell other developers that they have done literally |
35 |
> > nothing during the 2 years they're part of some project. That could |
36 |
> > discourage them from contributing. |
37 |
> > |
38 |
> |
39 |
> > You are also not supposed to try to offload yourself and distribute |
40 |
> > the work to them. That's bossing around, and it discourages others from |
41 |
> > actually doing anything. |
42 |
> > |
43 |
> > So, well, you're just supposed to smile and thank them for doing nothing |
44 |
> > for the project because otherwise they could feel offended |
45 |
> > and discouraged from doing anything, |
46 |
> > |
47 |
> |
48 |
> I am reading a lot of frustration in your comments. I know I have been on a |
49 |
> team(s) where this was the case and it was difficult to resolve. I've also |
50 |
> been that person who doesn't contribute but "hangs around". It might be |
51 |
> possible to think about better ways to measure progress and staffing than |
52 |
> just 'people'. Its pretty clear that 'people on the team' has little |
53 |
> relation to 'work done by the team'. So lets try to break that entirely? |
54 |
> |
55 |
> I want to be clear that "being friendly and nice" is not necessarily the |
56 |
> reason why we do not encourage the behavior you state. I suspect telling |
57 |
> people they have not done anything recently doesn't necessarily encourage |
58 |
> them to do stuff. Most of them have actual reasons for not contributing |
59 |
> (whatever they may be) and often a simple conversation doesn't magically |
60 |
> free up time for them, nor encourage them to start doing more. |
61 |
|
62 |
... |
63 |
|
64 |
> The most obvious thing to change is what I mentioned earlier, stop focusing |
65 |
> on "number of humans" and focus on things like "backlog of work for team" |
66 |
> and "velocity of team." Note that this requires ~agreement on what other |
67 |
> metric to use (like bug backlog) and tools to measure the backlog and |
68 |
> velocity. The GMN used to have some of these metrics for bugs. |
69 |
> |
70 |
> So one idea might be to measure bug backlog and bug velocity. Teams that |
71 |
> have a backlog that is not growing at a large rate, or even teams with |
72 |
> positive velocity (they tend to close all of their bugs eventually or keep |
73 |
> the backlog in a specific range) probably don't need operational help (they |
74 |
> are correctly staffed for their workload.) Teams that have a growing |
75 |
> backlog and negative velocity are understaffed (they will only get further |
76 |
> and further behind.) |
77 |
> |
78 |
> Note that these metrics don't necessarily care about the number of people |
79 |
> on the project, or how much each person contributes. It only cares about |
80 |
> the velocity of the project as a whole in relation to their bug queue. Its |
81 |
> certainly not how many projects will want to work (many teams want to keep |
82 |
> bugs open forever, for example.) In the past I've seen a bug "purgatory" |
83 |
> type label used for this, where bugs that someone looked at and decided |
84 |
> "well this is useful to keep open but isn't on the roadmap or we don't |
85 |
> necessarily plan on doing it" gets pushed into the "Purgatory"; it stays in |
86 |
> the bug system (open even!) but we don't count purgatory bugs as part of |
87 |
> the backlog. |
88 |
|
89 |
Definitely have to agree with this. I'm on the games team but I haven't |
90 |
done all that much for that project yet. That's largely because I'm |
91 |
lead of the Java team and I don't feel I'm doing enough there either. |
92 |
That doesn't mean I want to leave the games team and there is plenty |
93 |
I'd like to do given the time. I may still fix up the odd thing here |
94 |
and there and that's certainly better than nothing. |
95 |
|
96 |
I think there's also another angle to this, particularly when it comes |
97 |
to Java. I don't think it matters how many developers we can |
98 |
realistically get, the traditional approach to Java packaging stopped |
99 |
being scalable years ago. That backlog is growing and we're never going |
100 |
to catch it up short of taking extremely radical action. This is a hard |
101 |
problem to solve. I have some ideas but once again, it needs time. |
102 |
Knowing that our current course is hopeless is also very demotivating |
103 |
and that just makes a bad situation even worse. I don't want to waste |
104 |
time doing fruitless package bumps. When users hop onto IRC |
105 |
enthusiastically asking whether they can package some shiny new thing, |
106 |
it pains me to tell them that it's probably much harder than they think |
107 |
and they'd also be wasting their time. |
108 |
|
109 |
-- |
110 |
James Le Cuirot (chewi) |
111 |
Gentoo Linux Developer |