Structure

Differences between revisions 2 and 3
⇤ ← Revision 2 as of 2009-06-23 00:05:33 →
Size: 160
Editor: cpe-66-67-139-158
Comment:
← Revision 3 as of 2009-07-19 05:39:02 → ⇥
Size: 3742
Editor: host-69-144-245-173
Comment: Lets talk specifics =)
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
Draft Draft - This is a draft document with the intention of starting a conversation on how the UCLP wishes to structure membership.
Line 3: Line 3:
Please add your thoughts on structure in a section.
Line 5: Line 4:
== sample [use your name] == == Initial considerations - BodhiZazen ==
Line 7: Line 6:
1. Board: bla, bla [[BodhiZazen]] - As a starting point there seem to be two general themes.
 
 1. General Membership.
 1. Roles / Responsibilities / Sub-goups .
Line 9: Line 11:
2. Members: bla, bla
 * bla 1
 * bla 2		 I '''STRONGLY SUGGEST''' we track the team membership on Launchpad.

In general I believe members should renew membership annually (Launchpad will track this).


=== General Membership ===

The consensus seems to be that we wish this team to be as open as possible.

Do we want the team to be open, moderated, or restricted ? On Launchpad we have 3 options :
 {{{
'Moderated' means all subscriptions must be approved.
'Open' means any user can join without approval.
'Restricted' means new members can be added only by a team administrator.
}}}

Of these options, I suggest '''Moderated''' . This means people can request to join the team and we can approve them after we know who they are and how they wish to interact with the team. This can be as simple as offer advice / suggestions to as active as people wish to be with the team.

Potential criteria for general membership may also include :

 *Meet & greet - We should at least know who they are and what their interest is with the team.
 *Sign the [[http://www.ubuntu.com/community/conduct|CoC]] (to be tracked on Launchpad) ?
 *Additional suggestions anyone ?
 *Approval of new members by current members ? Admins ? At team meetings ? By simple majority vote ?

=== Roles ===

There are a number of opportunities for deeper involvement with the project. Potential categories might include (For now I will make only general suggestions):

 *Content contributors - People who develop and generate the actual content.

 *Teachers - People who actually teach, guide, or monitor "students" through the various courses. This may include leaders of IRC sessions in #ubuntu-classroom.

 *Administration - The actual site administrators.

My suggestion would be to first solidify these various roles and identify people willing to commit time and effort to them. I suggest that these then become sub-groups of the UCLP ('''''UCLP - Admin''''' for example) on Launchpad. It seems to make sense to make these groups '''Restricted'''.

In all likely hood, when the rubber hits the pavement, and it is time to accomplish "work", it is likely this second group will be the ones to either motivate others or accomplish the tasks themselves.

Potential criteria for membership to these groups:

 *Should we ask people to commit to an amount of time ? 2 hours / week ? more ? less ?
 *Sign the [[http://www.ubuntu.com/community/leadership-conduct|Leadership CoC]] ?
 *Demonstrate the quality of their work. Should we ask for references or samples of their work ?

=== Moderation ===

We should consider how we wish to moderate members. If there are conflicts between team members or if team members violate the CoC, how will we handle this ?

In general I would expect members to resolve conflict themselves, without external intervention. I suggest we consider how to proceed of members can not resolve differences themselves and thus require a 3rd part to facilitate the discussion.

If there is a violation of the CoC, we need a process to moderate. ?

Appeals - If a member does not agree with moderation, where do they go internal to the team ? External ?

=== Elections ===

How will we select our leaders ? How long do they serve ?

I believe 2 year terms are fairly standard.

Does this apply only to Admins ? Do we change the entire leadership structure at once, or do we keep some for continuity ?

Draft - This is a draft document with the intention of starting a conversation on how the UCLP wishes to structure membership.

Initial considerations - BodhiZazen

BodhiZazen - As a starting point there seem to be two general themes.

  1. General Membership.
  2. Roles / Responsibilities / Sub-goups .

I STRONGLY SUGGEST we track the team membership on Launchpad.

In general I believe members should renew membership annually (Launchpad will track this).

General Membership

The consensus seems to be that we wish this team to be as open as possible.

Do we want the team to be open, moderated, or restricted ? On Launchpad we have 3 options : 

  • 'Moderated' means all subscriptions must be approved.
'Open' means any user can join without approval.
'Restricted' means new members can be added only by a team administrator.

Of these options, I suggest Moderated . This means people can request to join the team and we can approve them after we know who they are and how they wish to interact with the team. This can be as simple as offer advice / suggestions to as active as people wish to be with the team.

Potential criteria for general membership may also include :

  • Meet & greet - We should at least know who they are and what their interest is with the team.

  • Sign the CoC (to be tracked on Launchpad) ?

  • Additional suggestions anyone ?
  • Approval of new members by current members ? Admins ? At team meetings ? By simple majority vote ?

Roles

There are a number of opportunities for deeper involvement with the project. Potential categories might include (For now I will make only general suggestions):

  • Content contributors - People who develop and generate the actual content.
  • Teachers - People who actually teach, guide, or monitor "students" through the various courses. This may include leaders of IRC sessions in #ubuntu-classroom.
  • Administration - The actual site administrators.

My suggestion would be to first solidify these various roles and identify people willing to commit time and effort to them. I suggest that these then become sub-groups of the UCLP (UCLP - Admin for example) on Launchpad. It seems to make sense to make these groups Restricted.

In all likely hood, when the rubber hits the pavement, and it is time to accomplish "work", it is likely this second group will be the ones to either motivate others or accomplish the tasks themselves.

Potential criteria for membership to these groups:

  • Should we ask people to commit to an amount of time ? 2 hours / week ? more ? less ?

  • Sign the Leadership CoC ?

  • Demonstrate the quality of their work. Should we ask for references or samples of their work ?

Moderation

We should consider how we wish to moderate members. If there are conflicts between team members or if team members violate the CoC, how will we handle this ?

In general I would expect members to resolve conflict themselves, without external intervention. I suggest we consider how to proceed of members can not resolve differences themselves and thus require a 3rd part to facilitate the discussion.

If there is a violation of the CoC, we need a process to moderate. ?

Appeals - If a member does not agree with moderation, where do they go internal to the team ? External ?

Elections

How will we select our leaders ? How long do they serve ?

I believe 2 year terms are fairly standard.

Does this apply only to Admins ? Do we change the entire leadership structure at once, or do we keep some for continuity ?

Learning/Structure (last edited 2009-08-29 16:40:29 by stpete)