Superceded by StreamlineMembershipApproval

Membership Management - 06 Nov 2006 https://features.launchpad.net/distros/ubuntu/+spec/membership also, see CC Nomination material for further earlier discussion

Concensus: We need further discussion

• Problem: CC is overwhelmed with membership requests.

• Problem: There are people who are challenged to complete the membership process. It should be easier.

• Problem: What really does being an Ubuntu member mean?

Documented process for creation of team councils. How should they interact with CC.

• Includes membership process
• Criteria

Definition of Membership

• Expectation of membership
• Examples
  • What are the benefits?
• Integration with locos. Who is local
  • Make it easier
• Currency Requirements
  • measurability
• Responsibilities

Definition of a Team

• Councils
• team membership
• address issues of cultural disconnects (??)
  • Language differences - can someone apply for membership without using English
• Possibly create a Team process (perhaps another spec)
• Establish as mentors to membership process

Membership Process

• reviewing existing documentation
• predefine application process and format (evidence of contribution)
• Examples of what we're looking for
• Pre-meeting review of applications
• Comment: Graduated membership scale will help incent people to maintain a high level of contribution
  • would need to think about this because we end up comparing various different areas which are dissimilar.
  • Might have reverse impact and drive people away (esp. from Asian countries -- cultural disconnects)
• Establish membership mentors (perhaps split off as separate spec)
  • perhaps establish a membership team
  • would require a short process
  • perhaps could help with testimonials
  • Could help eliviate the load on the CC
  • Comment: MOTU has seen people stop being maintainers and become almost full time mentors.
    • look at training more mentors
      • who would train the mentors? other mentors? or motus? in which case, this wouldn't alleviate the problem...
    • some people would rather be a member / personal choice
  • Need a way to ensure mentors are qualified to mentor
    • Comment: Create a restricted mentors team on Launchpad
    • Perhaps we can talk to the teams to see if they agree on who would make a good mentor
• Establish deadlines
• Comment: Might consider in the future requiring all membership applications approved by a mentor before going to CC
  • Sounds like a plan...
    • or at least require some sort of "sponsorship" (similar to Debian NM)?
• Include new members in the weekly news

Delegation of membership process to approved teams

• currently happening for Edubuntu and Kubuntu
• Comment: the only other team large enough to do this is the Forums
• Membership process should have been done through the CC for a period of time
• Teams must have large impact on CC
  • What about any Council members who aren't Ubuntu Members, if there are any? Are these demoted?
    • They should either not have a vote, or apply to be a member themselves
    • ubuntu_demon : I think the members of the Team Council should be made Ubuntu Members since the TC is to be trusted.
      • Will it be easier for them to become Ubuntu Member, having been councillers, or must they be assessed as with all other applicants, to be fair?
      • What if they have voted before?
• Comment: CC should give guidelines to these teams (Mako is currently defining as part of CC Nominations group)
• What about governance of teams without membership giving privs?
• Should we provide a governance council?

  Criteria for Delegation to CC

• Team councils should have
  • Mako: More than one person, at least 3

  • Regular reporting to the CC and the community (=> Ubuntu Weekly News; forum ambassadors?)

    • domain reporting / status update
    • membership, including new approvals
    • major conflicts / resolution decisions / escalations - vet for private information
    • once per meeting (IRC) / every month (Forums)
    • Make status public and push to UWN/Fridge as appropriate - exception is major conflicts above
• Council members must be Ubuntu Members
• should include a mentor
• Teams must be established (need to define)
• We should continue to work with existing councils
• Should create generalizable model for other team
• Need to define how standard should councils be
  • Define term lengths
    • initial concensus is less than or equal to 2 years
    • Team should define interval and present to CC for approval
  • We decided that term limits should not be applied because we feel the problems can be otherwise resolved by term lengths
• Need to define the relationship to the CC
• Need to define how council members are appointed
  • Mako said "team council members should be appointed by the CC with concurrence from the existing members of the team council"
• Potential to recall members should there be enough justification (need to define)

Action Points:

• Optimisation of key points with focus on low hanging fruit
  • membership application
    • Document process with reviews and samples with membership (official or adhoc)
    • Include best practices
    • Establish deadline for applications - 72 hours prior CC meeting
    • Move candidates to meeting start time
• Established teams should work with CC to develop a team charter
  • Need to develop a basic template with surrounding process

  • This means existings teams (Edubuntu & Kubuntu) should begin this now

Random Thoughts:

• What about peer-validated skills profiles? Would give us a way of tracking
  • evolution of Members...

Comments

* Text of an email I sent to the CC before this page appeared (--mdke):

I agree of course that the membership process is currently bottlenecked on
the Community Council ("CC" after this). However, I disagree that
delegating membership powers is the right way to deal with the problem.

What I've always found the best thing about the CC is that it provides a
centre for the community to interact, keeping up with the CC meetings was
a way to get to know everything that is going on in this incredibly varied
and wide community. And the membership process was a big part of that -
the CC, and everyone else, got to hear and talk about all the cool things
that are going on everywhere in the community.

I think that delegating membership powers to other bodies or teams will be
the beginning of the end of that for the Ubuntu community - it will start
dividing and people won't be in touch with other aspects of the community,
which will mean they will lose the ability to learn from those aspects.

Delegating membership is also a solution to the wrong problem, in my view.
The spec seems to assume that the problem is caused by the fact that the
community has grown too large for the governance process. That's not
right. Obviously, the community has grown, but the problem is caused, I
think, by the fact that the governance process is not efficiently applied.
CC meetings were frequently arranged at the last minute, unquorate, and
the plain fact is that the CC members are insanely busy and rarely have
time to deal with the issues that arise.

The solution to this isn't to delegate - now that we have a Community
Manager who can work full time on organising the governance process, I
think it will begin to work again. Things like ensuring meetings are well
attended by the CC, organised in advance, contacting potential members
whose personal pages may not yet be up to scratch, and so on, will clear
the bottleneck, and ensure that the community starts running smoothly
again.

Obviously, the bottleneck isn't just with membership - it's with all
issues that come to the CC. The process that Jono has already put in place
for streamlining the locoteam applications to the CC would equally
streamline other issues for the CC.

In sum, I'd urge you to think carefully before abandoning the centralised
governance process, because I think it has many really great advantages.