Workflow of the MC

assumtions

We need to start soon with the process - we might change the process while we work, but we need to announce it
we should keep it simple
we will end up with a flowing total of ~ 500 or 600 members for TDF, what means that we will have to process about 50 requests for approval / renewal per month next year.
we are bound to the ByLaws as written at CommunityBylaws#Membership

thoughts on tooling

the bylaws explicitly mention mailing lists at two places (requests to resign or to revocation). As we are bound to it anyway, I would also use a mailing list (or alias) for applications (and only applications). We could collect application requests there but track the status of application / membership somewhere else (wiki would be ok for me .. maybe OTRS later, when it is used by the admin team).

we should have a private mailing list to discuss applications and/or other issues

public vs. private work

I did not have a closer look, how "open" other communities handle requests. Afair, gnome publishes only the number of open requests and the list of accepted members. Details of the application or approval / denial are not published afaics. I would like this to handle in a similar way - e.g. we only publish numbers (maybe names [cornouws: rather not publish names] of applications in our queue and the names of accepted members. We might publish a very brief summary in case we reject membership application, but I'd rather not do so (just send it to the applicant) [cornouws: agree]. In case anyone disagrees with us, review of the application can be requested via SC/BoD and then we will report in public or private, as requested by SC/BoD.

Meetings and decision making

when and how should we prepare and actually make our decisions?
I'd prefer to have a session every two weeks (maybe once a week for periods with high number of applications). General agenda would be like:

- New (incoming) applications
  - collect the list of applications that came in within the last two weeks (starting next year, also "Affirmation of Membership" will processed) - this list should be published (or at least applicants should be notified, so that they know we received the application)
  - assign one MC-member to each application who is in charge [cornouws: but not solely responsible] to review the application (this should be based on the work area of the applicant. e.g. Fridrich might review developer's applications, Sophi UX, design, work in locale teams, André does l10n, QA, website)
- process reviewed applications
  - each application should have been reviewed as defined two weeks ago. We then decide to approve, reject or defer (if there are questions) the application.
  - applicants will be notified of this decision
  - accepted members will be published at the website

- other
  - forward revocation requests to the BoD with us commenting (I think, we should take care about this, but actually the BoD is in charge)
  - process resignation mails. According to the bylaws a resignation has immediate effect. Therefore we should remove the member from the website, but ask for confirmation.

Definition of merit

The most tricky thing might be how to define "merit" and how to review this. The only number we have so far is the "3 months of activity". So the application should at least state, what the first contribution was. Then we need a rough list of contributions (or information, how to verify contributions). E.g. we need the name that is used for code commmits, for bugreports, for editing the wiki and translations at pootle. With this, we might verify most of the "mesurable" contributions. For all the rest (user support, design work, research, local marketing. lobbiyng ...) we should ask for a short description of the acitivities, main mailing lists where the work was coordinated and names of already accepted members who we can ask to verify the contributions.

I think the form from Gnome is pretty good with all the info it get. http://foundation.gnome.org/membership/application.php

To draw the line for acceptance / denial might be very hard within the first months. I'd suggest to look at the (obvious) members we already have and use their contributions as reference. As I assume, that people listed at http://www.documentfoundation.org/foundation/ are our current members, the first official applicant might be Fridrich :)

I think the more precise the questions we ask the "easier" the acceptance/denial will be to review and get accepted in case of denial.

It will not work to try to come up with definitions in abstracto and in advance. That is why it would be good to have a mailing list where we could argue merits or lack thereof and have a clean record about our past reasoning. And give some public [cornouws: does that have to be public? when in fact we publish no names etc. I would not do this, unless the applicant asks the BoD for a review and that it is public] motivations during at least refusal would be good so that one avoids to be flagged as opaque and unfair.