(no commit message)
[wiki.git] / learn.mdwn
1 How does one "get involved with a SIPB project"? I’ve had countless prospective SIPB members ask me this question, but I have never really had a good answer for them. It’s a complicated, ill-defined process that even recent new members have difficulty describing. Even worse, no two people ever have the same experience, and what worked for one person may not work for another.
2
3 This essay is an attempt to describe this process. Not as a series of step-by-step instructions, because such a recipe doesn’t exist, but as a philosophy, an identification of a mindset that will get you asking the right questions, talking to the right people, and working on the right problems. We’ll take the huge task “Get involved with a SIPB project”, and continually divide it into smaller, more well-defined problems, until we are left with tasks that you can tackle head-on.
4
5 Let’s get started.
6
7 Level 0: Milestones
8 -------------------
9
10 What does it mean to have joined a project?  The most important aspects are soft and hard to quantify, but there are some hard and unambiguous technical milestones you can achieve.  Most projects have the following two:
11
12 * Commit access (or “commit bits”), which indicate that you have permission to directly push source code changes to the repository of the project.
13
14 * Administrative access (also called “root bits” or just “root”), which indicate that you have access to the ``root`` account on production hardware and can install software, do system maintenance, etc.
15
16 On some projects, commit bits is equivalent to root, while on other projects, you may be able to commit code, but cannot deploy it without root.
17
18 But even if you don’t have commit access, your level of involvement can vary. As you become more involved with the project, you will start to be able to check off more things off this list:
19
20 * Do you know all of the maintainers involved with the project?
21
22 * Can you describe the project to an interested outsider?
23
24 * Have you used the project yourself as an enduser?
25
26 * Do you know (roughly) what all of the components of the project do?
27
28 * Have you setup an instance of the project’s software and/or configuration from scratch?
29
30 * Have you answered a user question?
31
32 * Have you submitted a patch and gotten it accepted?
33
34 * Have you written documentation for the project?
35
36 * Have you discovered a security vulnerability in the project?
37
38 * Do the project maintainers trust you?
39
40 * (probably more)
41
42 All of these exercise different dimensions of involvement with the project, and you don’t have to do all of them to get root! But there are a lot of ways to contribute without having bits, so don’t get discouraged if you haven’t gotten them yet.
43
44 Level 1: Getting in touch
45 -------------------------
46
47 The single most important first step is setting up lines of communication with the current set of project maintainers.  This can be tricky, because in general every project has a different preferred medium of communication, and a different set of social conventions around this medium.
48
49 ...
50
51 Level 1: Fixing bugs
52 --------------------
53
54 Level 1: Helping users
55 ----------------------
56
57 Level 1: Writing new software
58 -----------------------------
59
60 Level 1: System administration
61 ------------------------------
62
63 Level 2: Learning infrastructure
64 --------------------------------
65
66 Level 2: Identifying problems
67 -----------------------------
68
69 Level 2: Understanding problems
70 -------------------------------
71
72 Level 2: Getting code
73 ---------------------
74
75 Level 2: Navigating code
76 ------------------------
77
78 Level 2: Modifying code
79 -----------------------
80
81 Level 2: Running code
82 ---------------------
83
84 Level 2: Submitting code
85 ------------------------