org/meetings/2015SummerDevMeeting/MembershipProcess.md

-== Current state ==
+## Current state
 
 Here are membership-like features that we currently have:
 
@@ -26,7 +26,7 @@ tor-internal@. It's just that it's general Tor Project coordination.
 This should happen on a public mailing list. We do need to better refine
 what should go on tor-internal@.
 
-== Where do we go? ==
+## Where do we go?
 
 Mozilla has a clear division betwen: community members, contributors,
 employees. We basically can replicate that structure.
@@ -47,7 +47,7 @@ What you do get when you become a member?
    hardware, or publicity material.
  * You get some kind of transitive trust.
 
-== Membership process ==
+## Membership process
 
 What do I need to become a member?
 
@@ -67,7 +67,7 @@ What do I need to become a member?
 There might be exceptions. But this would be the documented process that
 is visible to external people.
 
-'''EDIT:'''
+**EDIT:**
 
 How do I become a member?
 
@@ -84,16 +84,16 @@ Actual process:
  * The account manager review the contributions and if they are fond to be sufficient, process to write an email to the internal mailing list with a summary of the application and ask for any vetos.
  * After two weeks, if no current project member vetoed the application, the account manager opens an OpenPGP Trac ticket to ask TSA to create the account.
 
-== Further discussions ==
+## Further discussions
 
-=== Roles ===
+### Roles
 
 Who is going to ensure the process runs? Do we want application
 managers? Who is going to review the submissions?
 
-'''EDIT:''' Let's start with one person who is authoritative on who is a member or not. So for applications they would send summaries and seek vetos, and finally create the ticket to get the account added if everything is right.
+**EDIT:** Let's start with one person who is authoritative on who is a member or not. So for applications they would send summaries and seek vetos, and finally create the ticket to get the account added if everything is right.
 
-The “Tor Project Account Manager” (like [https://wiki.debian.org/DAManager the one in Debian]) would have authority to decide who is accepted or removed from the project.
+The “Tor Project Account Manager” (like [the one in Debian](https://wiki.debian.org/DAManager)) would have authority to decide who is accepted or removed from the project.
 
 It might be better if the account manager is not contracting or employed by the company.
 
@@ -101,7 +101,7 @@ Meanwhile, Roger has so far acted as such gatekeeper. But we don't want Roger to
 
 (Damian declined has he doesn't want to be the one making the decisions.)
 
-=== Loosing membership ===
+### Loosing membership
 
 We need a process on how people lose membership.
 
@@ -117,45 +117,45 @@ active for a year and ask them if they want to stay subscribed.
 We could elaborate on that, e.g. if you don't do stuff for 1 year, then
 you are declared as “emeritus” until you can do things again.
 
-'''EDIT:'''
+**EDIT:**
 
- * ''Missing In Action case'': Monthly or quaterly review of current members and see if anyone has been inactive for a while (like a year). Let's ping them by email and ask if they plan to get back contributing soon. In case not, or they are unresponsive then, they are moved to the “emeritus” status. The idea is that they can be fast tracked if they start contributing again regarding the whole joining process.
- * ''Suspension case'' and ''expulsion case'': Complaints will be received by the moderation team (see Code of Conducts discussions). Actions will be decided there.
+ * _Missing In Action case_: Monthly or quaterly review of current members and see if anyone has been inactive for a while (like a year). Let's ping them by email and ask if they plan to get back contributing soon. In case not, or they are unresponsive then, they are moved to the “emeritus” status. The idea is that they can be fast tracked if they start contributing again regarding the whole joining process.
+ * _Suspension case_ and _expulsion case_: Complaints will be received by the moderation team (see Code of Conducts discussions). Actions will be decided there.
 
-=== Conflicts or concerns amongst members ===
+### Conflicts or concerns amongst members
 
 How can one raise concerns about another member?
 
-'''EDIT:''' They should be addressed to the moderation team. If the complaints are about any members of the moderation team, then they should go to one of the board member.
+**EDIT:** They should be addressed to the moderation team. If the complaints are about any members of the moderation team, then they should go to one of the board member.
 
-=== What kind of contributions do we recognize? ===
+### What kind of contributions do we recognize?
 
 Code is obvious. What about advocacy, translation, UX, etc.?
 
 How about relay operators? Is running a relay enough to apply?
 How about dir. auth. operators?
 
-'''EDIT:''' We make a distinction between the Tor Project and the Tor network. Helping with the network is not the same as helping building the software or advocating for the tools. People who are just relay operators or just dir. auth. operators can't apply for membership.
+**EDIT:** We make a distinction between the Tor Project and the Tor network. Helping with the network is not the same as helping building the software or advocating for the tools. People who are just relay operators or just dir. auth. operators can't apply for membership.
 
-=== Employees and contractors ===
+### Employees and contractors
 
 We should not require employees or contractors to be members. How do we make that work?
 
-'''EDIT:''' If there's a internal mailing list dedicated to company matters, then we don't need to add all employees and contractors to the tor-internal@ list. If employees or contractors need to work on project-wide stuff, they can also use the newly created tor-project@ mailing list. ''Does people in the company think otherwise?''
+**EDIT:** If there's a internal mailing list dedicated to company matters, then we don't need to add all employees and contractors to the tor-internal@ list. If employees or contractors need to work on project-wide stuff, they can also use the newly created tor-project@ mailing list. _Does people in the company think otherwise?_
 
 In any cases, we are likely to get different subscriber list between tor-assistants@ and tor-internal@ as company people might need to be on tor-assistants@ and they would not necessarily be members. Or can we move tor-assistants@ to Request Tracker or something less crazy than the current situation?
 
-=== Migration ===
+### Migration
 
 How do we move from the current unspecified situation to having actual members?
 
-'''EDIT:''' Currently we have people not actively contributing to the project except by sending a message to the internal mailing list from time to time. What do we do? Maybe we can consider than participating in the private mailing list is a valuable contribution. Although most discussions related to the project should be moved to a tor-project@ mailing list. In any cases, we should remove people who say the want to read tor-internal@ but never participate in any ways.
+**EDIT:** Currently we have people not actively contributing to the project except by sending a message to the internal mailing list from time to time. What do we do? Maybe we can consider than participating in the private mailing list is a valuable contribution. Although most discussions related to the project should be moved to a tor-project@ mailing list. In any cases, we should remove people who say the want to read tor-internal@ but never participate in any ways.
 
 The Account Manager should work with Roger (?) to review everyone currently subscribed to tor-internal@ and if they have been contributing lately, then have them formally agree on the mission statement and the code of conduct. If so, create missing LDAP accounts or switch a flag for the currently existing account.
 
-=== Name ===
+### Name
 
-'''EDIT:'''
+**EDIT:**
 
 Is “Tor Project Member” the right name?
 
@@ -169,9 +169,9 @@ ArchLinux uses “Trusted Users”.
 
 “Volunteers” would not be good as some people “in the project” are going to be employees or contractors.
 
-== Concrete things to be done to make this happen ==
+## Concrete things to be done to make this happen
 
- * ~~Create a tor-project@ public mailing list.~~ '''DONE''': 2015-10-17
+ * ~~Create a tor-project@ public mailing list.~~ **DONE**: 2015-10-17
  * Create more or one of tor-employees@ / tor-company@ mailing list.
  * Define a policy of what should go on tor-internal@.
  * Migrate what's relevant to the internal SVN and corporate SVN into Git/Sparkleshare repositories. We different repositories for different user groups. Company stuff should go in a different directory than press which can be used by some members and some employees, than stuff that is for members (like the key to the internal IRC channel).
@@ -179,7 +179,7 @@ ArchLinux uses “Trusted Users”.
  * Review and refine the membership process.
  * Review the idea of the “Tor Project Account Manager”. Decide on who that could be.
 
-== Other random things ==
+## Other random things
 
 We probably want to make the distinction between
 community/members/employee more visible (e.g. to journalists).