1 |
On 04/03/2010 06:19 AM, Tobias Scherbaum wrote: |
2 |
>> And still, when someone tries to fix things in such an understaffed herd |
3 |
>> people go all territorial and are like "omg u touched my package". |
4 |
>> Right now I'm quite confused what our project strategy seems to be, as |
5 |
>> far as I can tell there's one group aiming for an aesthetical optimum |
6 |
>> and the other group just wants to get things fixed. And they are not |
7 |
>> cooperating well ... |
8 |
> |
9 |
> I for one can't say I had any territorial problems when touching |
10 |
> packages belonging to other devs or herds - it's just a problem if you |
11 |
> screw up. |
12 |
> |
13 |
|
14 |
Agreed - if you ping the herd in advance, and get an OK (or at least no |
15 |
reply for a few days), and then you make some simple fixes to their |
16 |
packages, it is very unlikely that you're going to have any complaints. |
17 |
|
18 |
If you send the the proposed patch in advance and let them review it, |
19 |
and you get no complaints, you're even more clearly in the right. |
20 |
|
21 |
If you don't notify them at all, or you notify them and do a cvs commit |
22 |
3 minutes later, or if you completely redesign their ebuilds in addition |
23 |
to fixing a 1-line problem, then you're going to get complaints. |
24 |
|
25 |
Nobody minds help. People do mind when somebody drops by to help them |
26 |
for 5 minutes and they're stuck with the aftermath. We don't "own" our |
27 |
packages, but existing maintainers have at least shown a long-term |
28 |
commitment to them (however strong) and that should at least be respected. |
29 |
|
30 |
On other topics in this thread: |
31 |
|
32 |
I agree wholeheartedly that whenever possible "just do it" is a good |
33 |
approach - especially when you're talking about documentation and |
34 |
external websites/etc. Modifications to things that already exist are |
35 |
less amenable to "just do it." |
36 |
|
37 |
I really think that the Gentoo recruitment process needs improvement. |
38 |
Right now it seems like a LOT of effort is required both to become a |
39 |
Gentoo dev and to help somebody become a Gentoo dev. That means we have |
40 |
great people, but not many of them. |
41 |
|
42 |
I think the problem is that our recruitment process uses the ability to |
43 |
answer complex technical and organizational questions as a way to assess |
44 |
maturity. I think that maturity is far more important than technical |
45 |
skill in a distro - a mature person will recognize their own limitations |
46 |
and exercise due diligence when stepping outside of them. Instead of |
47 |
playing 20 questions and going back and forth with recruits, maybe a |
48 |
better approach would be to cut down the questions dramatically (or more |
49 |
clearly put their answers in the documentation), and then use other |
50 |
approaches like references and interviews. A new recruit might be given |
51 |
the names of 5 devs that they will need to interview with for 30-60 |
52 |
minutes by phone or IRC (preference on phone), and they will need to |
53 |
submit references, who will be contacted. When we hire people at work |
54 |
we don't play trivial pursuit with them, we use an interview to get a |
55 |
feel for what they're like and how they handle situations, and we screen |
56 |
resumes and references to determine experience. I'm sure any of the |
57 |
professional linux distros would work in the same way, but perhaps |
58 |
somebody should ask around and see how it is done elsewhere. |
59 |
|
60 |
So, now instead of a recruiter having to spend hours helping somebody |
61 |
through quizzes without giving them answers, instead they just send them |
62 |
a list of interviewers, and collate the results. Any interviewer will |
63 |
just need to spend 30 minutes on an interview and 10 minutes on a |
64 |
writeup. Plus, the whole process will make Gentoo a bit more human. |
65 |
|
66 |
Rich |