clarify that ktadd/ktremove are kadmin subcommands
[wiki.git] / learn.mdwn
index 6d700589bbc71629e90be9c2a78926dcfd494434..3fac2b06c75929508263f59f348c60043383a4fd 100644 (file)
@@ -4,12 +4,63 @@ This essay is an attempt to describe this process. Not as a series of step-by-st
 
 Let’s get started.
 
-Level 0: Joining a project
---------------------------
+You may also be interested in this document: https://etherpad.mozilla.org/process
+
+Level 0: Motivation
+-------------------
+
+How do you pick a SIPB project to contribute to?  One way to look at this problem is finding a project whose goals and community align with yours, so that contributing to the project is engaging and fun.
+
+* Does the project solve a problem that you also want to solve?
+
+* Does the project offer opportunities to learn technical skills that you would like to acquire?
+
+* Does the project have a good way for you to start contributing, e.g. it is written in a programming language you already know or want to learn, or it is running a system you have some familiarity with?
+
+Level 0: Milestones
+-------------------
+
+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:
+
+* Commit access (or “commit bits”), which indicate that you have permission to directly push source code changes to the repository of the project.
+
+* 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.
+
+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.
+
+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:
+
+* Do you know all of the maintainers involved with the project?
+
+* Can you describe the project to an interested outsider?
+
+* Have you used the project yourself as an enduser?
+
+* Do you know (roughly) what all of the components of the project do?
+
+* Have you setup an instance of the project’s software and/or configuration from scratch?
+
+* Have you answered a user question?
+
+* Have you submitted a patch and gotten it accepted?
+
+* Have you written documentation for the project?
+
+* Have you discovered a security vulnerability in the project?
+
+* Do the project maintainers trust you?
+
+* (probably more)
+
+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.
 
 Level 1: Getting in touch
 -------------------------
 
+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.
+
+...
+
 Level 1: Fixing bugs
 --------------------
 
@@ -22,6 +73,9 @@ Level 1: Writing new software
 Level 1: System administration
 ------------------------------
 
+Level 2: Learning infrastructure
+--------------------------------
+
 Level 2: Identifying problems
 -----------------------------