1 |
I wrote most of this a while ago but didn't get round to finishing it. |
2 |
This seems appropriate at this time, so here it is :) |
3 |
|
4 |
Here are some small *suggestions* for how I think we can motivate users |
5 |
on Bugzilla to contribute more, and to contribute more often. I'm not |
6 |
suggesting this be enforced as policy, but it would be nice to see other |
7 |
developers giving this some thought. I'm far from perfect here, but I am |
8 |
working on sticking to my own suggestions more and more. |
9 |
|
10 |
Remember that Bugzilla is the only way we communicate with most of our |
11 |
external contributors so it is important to make them feel appreciated |
12 |
and give them a good impression of the Gentoo developer community. |
13 |
|
14 |
1. Don't bitch at contributors |
15 |
|
16 |
Even if they did something totally wrong, violated all known policies, |
17 |
and you are *sure* they just filed the bug to annoy you, don't write |
18 |
aggressive sounding responses. |
19 |
|
20 |
Reasons being: |
21 |
- You'll reduce the chances they'll think about contributing again in |
22 |
the future |
23 |
- They probably won't listen to a word you say, yet will feel the need |
24 |
to respond |
25 |
- Bugzilla is a public medium, and other potential contributors (who |
26 |
maybe wouldn't have made such 'obvious' mistakes) will be put off when |
27 |
reading the aggressive dialog. |
28 |
(I'm not suggesting that you send abuse privately instead!) |
29 |
- Like we aren't paid to fix bugs, the users aren't paid to file them: |
30 |
at the end of the day, someone went out of his/her way to file the bug, |
31 |
to try and help. |
32 |
|
33 |
2. Be careful with INVALID resolutions |
34 |
|
35 |
The term invalid _is_ harsh in bugzilla context, so make sure you write |
36 |
a quick thankful-sounding comment to go with it. |
37 |
|
38 |
Maybe we should consider alternatives. I quite like the NOTABUG |
39 |
resolution they have on the GNOME bugzilla. |
40 |
|
41 |
Marking bugs as duplicates is also dodgy ground: Comments like "Please |
42 |
search" can easily be taken the wrong way. I'm probably asking too much |
43 |
for people to spend lots of time thinking up appreciative duplicate |
44 |
messages, however... |
45 |
|
46 |
3. Always record contributions by name |
47 |
|
48 |
If you commit something in response to a bug report that has been filed, |
49 |
always thank the user by full name (and bug number) in the ChangeLog and |
50 |
commit message. |
51 |
|
52 |
Do the above even if you already knew about the bug (i.e. you would have |
53 |
committed the same fix even if the user hadn't alerted you). |
54 |
|
55 |
This also applies for ebuild requests, ebuild submissions, and version |
56 |
bump requests/submissions. Might sound pointless for 'trivial' |
57 |
reports/requests but it is important to credit the user if they have |
58 |
gone to the trouble of filing a bug. |
59 |
|
60 |
This also applies to contributors who you know well, contributors who |
61 |
you have named 9999 times before, and other Gentoo developers too. |
62 |
|
63 |
4. Give the user a chance to make minor corrections |
64 |
|
65 |
If a user contributes a patch/ebuild which is slightly wrong, and the |
66 |
issue is non-critical, don't immediately correct it on their behalf and |
67 |
commit it to get the bug out of the way. |
68 |
|
69 |
Instead, provide an explanation of their mistake and give the user a day |
70 |
or two to correct it and attach an updated version. This has the bonuses |
71 |
that the user definately won't repeat that mistake in future |
72 |
contributions, and they will have the nice feeling of full credit for |
73 |
the contribution after you name them in the ChangeLog :) |
74 |
|
75 |
If they don't respond in that time, make the correction yourself and |
76 |
commit it anyway. |
77 |
|
78 |
5. Be thankful when marking FIXED |
79 |
|
80 |
When marking a bug as FIXED, I often forget that the user has tested 4 |
81 |
kernel versions, moved their network card over to another computer, |
82 |
filed an identical bug report upstream, tested the solution, and |
83 |
reported back to me. |
84 |
|
85 |
I think a short note of thanks in the bugzilla comment can go a long way |
86 |
(suggestion: thank them for something in particular so that it doesn't |
87 |
sound so generic). |
88 |
|
89 |
6. Don't forget about email |
90 |
|
91 |
As a Gentoo developer, you have been automatically granted the ability |
92 |
to sound important and make others feel important too. |
93 |
|
94 |
When Seemant mailed me over 2 years ago, I was a relative idiot and was |
95 |
a new Gentoo user at that time. It felt great to receive a complimentary |
96 |
email from a well-known and respected Gentoo developer, and that email |
97 |
eventually led to me becoming a developer myself (amongst other things!). |
98 |
|
99 |
I've had the same kind of effect on people since then, for example, I |
100 |
sent a very quick "thanks" mail to the guy who authored the wordpress |
101 |
theme I run on my weblog, and he was overjoyed that I was using it - he |
102 |
happened to be a Gentoo user who already read my blog via the Planet site. |
103 |
|
104 |
There probably aren't many situations where you would email a user who |
105 |
communicates with you on bugzilla. But don't forget about this nice |
106 |
ability that we have :) |
107 |
|
108 |
|
109 |
|
110 |
That's all I can think of for now. I'd certainly be interested to hear |
111 |
any comments on the above and similar suggestions that others may have. |
112 |
|
113 |
Daniel |
114 |
-- |
115 |
gentoo-dev@g.o mailing list |