1 |
On 4 June 2010 00:55, Jeroen Roovers <jer@g.o> wrote: |
2 |
> On Thu, 3 Jun 2010 22:35:04 +0200 |
3 |
> Ben de Groot <yngwin@g.o> wrote: |
4 |
> |
5 |
>> Also, there are herds that have several members, but none of them is |
6 |
>> really active (games, most of the desktop-* herds, etc.). This also |
7 |
>> leads to users being discouraged because the bugs they file are left |
8 |
>> ignored. |
9 |
>> |
10 |
>> This needs a structural solution. I think we need a team to |
11 |
>> systematically look at open bugs and to notify the community of such |
12 |
>> problematic herds. I imagine this would be a QA subproject. |
13 |
> |
14 |
> That would basically be a task other than bug-wranglers, but jakub used |
15 |
> to do all this and I do it sometimes, among a few others who either |
16 |
> just scratch an itch or take a general interest. Maybe the |
17 |
> bug-wranglers project can be extended since it at least has some active |
18 |
> people (not just developers), but as it now stands there are again 150 |
19 |
> unassigned bugs after only a week (up from ~40 since the last |
20 |
> reassignment run I believe). |
21 |
|
22 |
This is indeed not bug-wrangling. It's more "follow-up", making sure |
23 |
things don't fall between the cracks *after* they have been assigned. |
24 |
|
25 |
Because currently they do. Instead of involving more users with |
26 |
development, we discourage them because their bugs are ignored. |
27 |
Especially users who come with fixes and patches should be thanked and |
28 |
encouraged. But too often they are frustrated because their bug is |
29 |
assigned to a dev or herd who is inactive and unresponsive (for |
30 |
possibly very valid reasons) and nobody is picking up the slack. |
31 |
|
32 |
I think we can do better, and I believe there are enough people who |
33 |
care, who would volunteer to form a team to take care of this. |
34 |
|
35 |
> "Calling in" QA as such usually isn't really beneficial. |
36 |
|
37 |
I'm sorry I wasn't clear enough on this point. I'm not "calling in" |
38 |
QA. I say we need to form a new team to tackle this long-standing |
39 |
problem. Like bug-wranglers, these volunteers would not need to be |
40 |
devs, but could just as well be users who want to contribute. And they |
41 |
could be joined by devs, who like me think this is an important issue |
42 |
to address. |
43 |
|
44 |
I think that this new team would naturally find its place within |
45 |
Gentoo as a QA subproject, as this problem has a lot to do with QA |
46 |
concerns. But it could also be linked to bug-wranglers or be |
47 |
independant. That's mostly bikeshedding for me. I think some QA |
48 |
supervision might be beneficial, especially since QA has the authority |
49 |
to step in in certain cases. But let it be clear that I'm NOT saying |
50 |
"this needs to be done, and QA must do it." I'm saying "this needs to |
51 |
be done, and we should ask some people to volunteer." |
52 |
|
53 |
>> Then we also need some structure to redirect some dev love to these |
54 |
>> problematic areas. We need to advertise these needs more, to get |
55 |
>> trusted users to proxy-maintain. We need to streamline the recruitment |
56 |
>> process to make it easier for people who want to volunteer to become |
57 |
>> devs. And I could go on for a while. There are a lot of areas where |
58 |
>> Gentoo has a lot of room for improvement, and they all interlock. |
59 |
> |
60 |
> All these problems seem to come down to the fact that we're |
61 |
> understaffed in most departments. |
62 |
|
63 |
I think we can work on this from two sides: |
64 |
|
65 |
1: Motivate the people we have. Make their work more efficient. Find |
66 |
out why people are retiring. For people who are retiring for |
67 |
Gentoo-internal reasons, let's improve things so they will be more |
68 |
motivated to stay. |
69 |
|
70 |
2: Make it easier and more rewarding for people to start contributing. |
71 |
We can expand proxy-maintainership (many users don't even know this is |
72 |
possible). We can reform the recruitment process, so that it will be |
73 |
less of a bottleneck (for example by putting much more responsibility |
74 |
into the hands of our mentors, like we discussed on IRC). We also need |
75 |
to communicate better what we need. Put specific recruitment calls on |
76 |
our frontpage, on the forums. More actively engage contributing users |
77 |
(on bugzilla, sunrise, etc.) to set the next step. |
78 |
|
79 |
> Setting up yet another project isn't going to help much. |
80 |
|
81 |
Not by itself. But in my opinion this is a structural problem that |
82 |
needs a structural solution. If you have other ideas of how to do |
83 |
this, let's hear them and discuss them, and find out which we think |
84 |
are likely to give us the best results. My concern is that we tackle |
85 |
the problem. The how is just a tool. |
86 |
|
87 |
> Just looking |
88 |
> at open bugs (bugzilla can help you figure out which bugs might need |
89 |
> someone's particular attention). What might help right now is look at |
90 |
> the herds.xml data and combining that with activity rates of the |
91 |
> developers in all herds. Herds with few developers and lots of open |
92 |
> bugs is something you could calculate and filter down into a monthly or |
93 |
> weekly report you send to a mailing list (probably dev-announce?). |
94 |
|
95 |
Yes, this could be a very valuable tool. |
96 |
|
97 |
>> I believe we need to formulate a vision of what we want Gentoo to be, |
98 |
>> and then develop strategies of how to get there. Having a team that |
99 |
>> systematically looks at the state of herds as well as open bugs is |
100 |
>> --in my opinion-- a crucial first step to adress some of the |
101 |
>> structural problems that have plagued Gentoo for years. |
102 |
> |
103 |
> Do you mean we should redefine what Gentoo is about, to satisfy the lack |
104 |
> of active developers? Bring down the number of packages? Or address the |
105 |
> staff shortage? That last one is rather old, as recruiters have been |
106 |
> clamouring for help for years now. |
107 |
|
108 |
Not so much redefine, but clarify. What is Gentoo really about? What |
109 |
kind of distro are we? What are our goals? What are our values? |
110 |
|
111 |
We want to be the best distro for power users. At least, that is how I |
112 |
have always understood Gentoo. What else is part of that vision? Can |
113 |
we put that into a clear mission statement, into defined goals and |
114 |
values? |
115 |
|
116 |
This is going a bit off-topic. Maybe we should split this part off |
117 |
into its own discussion? |
118 |
|
119 |
A clear vision and defined goals will show us what our priorities are. |
120 |
And in my vision for Gentoo nothing falls between the cracks. So it |
121 |
would be a priority to detect those cracks, and to recruit volunteers |
122 |
to close specific holes. If we agree on what our priorities are, on |
123 |
what our goals are, we have a better change to succesfully attain |
124 |
them. |
125 |
|
126 |
Cheers, |
127 |
Ben |