1 |
Thomas Anderson wrote: |
2 |
> It seems to me you're on a irc-hate rampage. There are many devs who |
3 |
> rarely, if ever, go on irc. The _only_ requirement is that you conduct |
4 |
> a real-time interview with a recruiter. |
5 |
|
6 |
I have to agree with this sentiment - I have nothing against IRC but it |
7 |
is a bit too realtime for me to be on it routinely. However, I didn't |
8 |
have any trouble spending time with my mentor on IRC as it is a much |
9 |
more productive way to learn the ropes. Sure, lots of time was spent |
10 |
reading docs/etc, and doing ebuild exercises/etc. However, the direct |
11 |
conversations were also an invaluable part of the process (even if it is |
12 |
hard to schedule an hour just sitting at the keyboard with family/etc). |
13 |
|
14 |
Plus, it is essential that there be some kind of interviewing process to |
15 |
become a dev. A gentoo dev potentially has the power to hose the |
16 |
systems of everybody running gentoo - so we owe it to ourselves and our |
17 |
user communities to vet any candidate for this position. Sure, we want |
18 |
to know that they know how to write ebuilds, but we also want to know |
19 |
that they have a good attitude and some common sense as well. We count |
20 |
on devs to understand their own limitations and to not try to |
21 |
singlehandedly revamp baselayout/etc without careful coordination with |
22 |
the rest of the community. |
23 |
|
24 |
I also echo what has been said about projects like Sunrise and overlays |
25 |
as being good gateways into gentoo. |
26 |
|
27 |
Oh, I'm not sure I agree that new devs should be grilled to the n'th |
28 |
degree on obscure ebuild knowledge. It is more important that they know |
29 |
where to go and have demonstrated the ability to use this knowledge than |
30 |
it is for them to have this memorized. If it takes a dev 28 hours of |
31 |
tinkering to get an ebuild right I could care less as long as it is |
32 |
right on the first actual commit. When it comes to package management |
33 |
being careful is generally more important than being quick. It is also |
34 |
critical that devs be able to interact in a professional manner and |
35 |
relate well to our user community as well. |