Unifying LoCo Team Resources w/Launchpad

Include(LoCoMenuHeader)

Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.

• Launchpad entry: https://features.launchpad.net/distros/ubuntu/+spec/unifying-loco-resources-with-launchpad

• Created: 09 Nov 2006

• Packages affected: Launchpad

• Owner: [wiki:JonoBacon Jono Bacon]

• Drafter: [wiki:JoeyStanford Joey Stanford]

Summary

This spec discusses expanding Launchpad to centralize and ease the creation and management of LoCo team frequently requested resources.

Rationale

Right now, LoCo teams need a collection of resources to work. Of course, these vary between different teams, but there is a core of resources that are commonly used by teams. This includes essential resources such as:

• Website
• Mailing list
• IRC
• Domain
• Forums

But, also includes non-essential, but useful resources such as:

• Planet
• User map

At the moment some of these resources are centralised (mailing lists, IRC, domains), but many are not and the LoCo team need to research, install and run seperate software to get up and running. In addition to this, there is the problem of commonality of resources. As an example, there is no central place for all of the LoCo team planets, they are instead interspersed across the net.

Use cases

• Joey is the lead of an approved LoCo team. He wants to be able to create common resources for his team such as mailing lists, webpages, and websites. Unfortunately he is not technical and doesn't have hosting resources available to him. He would procede to his LoCo Team's entry in Launchpad as the owner/administrator and select the resources he needs from a menu of available services. These are then created and mailed back to him and/or the members listed on the team page.

• Og is a new/perspective member of a LoCo team. His local contact provides him with the launchpad address for his team. He signs up for launchpad, joins the team, and then from a single page adds himself to the mailing list, users list, adds his blog to the team's planet, and signs up to the team's forums. He is now fully connected with the team.

• Jono is the community leader and he wants to view details about a specific LoCo team. He heads to launchpad's master LoCo team and selects on the Colorado Loco Team. Launchpad displays the team general contacts, the education contacts, the marketing contacts, and the local CD distribution contacts. Launchpad displays the timezone, the various communication channels (web, irc, planet, forums, etc.), and a link to their wiki entry.

• Dave is a non-Ubuntu member but an active member in his LoCo team. He communicating with local sponsors for an upcoming event and would like to use and publish a more professional email address than crazyclassicalguitar@mail.yahoo.be. He heads over to his Launchpad account and enables his LoCo team email alias. He becomes dave@beloco.ubuntu.com which he then uses on all communications.

Scope

This spec covers feature requests for Launchpad. These are primarily data elements for better integration. Launchpad should in no way take over functions (e.g. planet.launchpad.net) but rather be the integration point for those listed in this spec.

This spec assumes that every LoCo team will have a Launchpad group and that members of each LoCo, as per the current process, will have a Launchpad id. Signing of the CoC, while required procedurally, is not currently required for this spec.

Design

We would like to enhance Launchpad by having it contain and maintain additional data fields of interest to LoCos. Data fields will generally be attributed to a LoCo Team record and may or may not be displayed. Each data field may have an associated policy governing it's use.

We would also like to the explore integration with commonly used tools such as mailman and planet.

Implementation

1) Data elements to store inside Launchpad to LoCo team record:

• LoCo Team flag

  • display/not hidden
  • policy=set by Jono/Launchpad admin only
• Approved Team Flag
  • display/not hidden
  • Policy=set by Jono/Launchpad admin only

• LoCo team primary contact flag

  • Contact links to Launchpad record
  • More than one contact allowed
  • display/not hidden
  • Policy=set by team owner/administrator only

• LoCo timezone

  • display/not hidden
  • Policy=set by by team owner/administrator only

• LoCo Mailing List Information

  • display/not hidden
  • Policy=list set by team owner/administrator only
  • May be Ubuntu or Non-Ubuntu Sponsored
  • Allow basic mailman automation functions
    • subscribe
      • regular
      • digest
    • unsubscribe
    • password change and advanced features should forward user to mailmain interface
  • Allow Owner/Administrator to request creation of Ubuntu mailing list
    • Policy=allowed by team owner/administrator only

• LoCo Website Information

  • display/not hidden
  • Policy=set by team owner/administrator only
  • May be Ubuntu or Non-Ubuntu Sponsored
  • Allow creation of Ubuntu sponsored website
    • Policy=must be approved team,allowed by team owner/administrator only

• LoCo official IRC channel

  • display/not hidden
  • Policy=list set by team owner/administrator only

• LoCo Wiki Page

  • display/not hidden
  • Policy=list set by team owner/administrator only
• user email alias for approved teams (Related issue, see below)
  • display/not hidden
  • opt-in
  • Policy=must be approved team

2) Launchpad team will establish a master LoCo team (like the current translation team structure) and each LoCo team, approved or not, will be organized under it.

3) Creation of teams should occur in the same basic manner as it does for other towered teams today.

• The LoCo team creates a Launchpad team using the appropriate naming convension. e.g. Ubuntu-Colorado, Ubuntu-Australia

• The LoCo team owner emails the Ubuntu Community Manager (i.e. Jono Bacon) to bring their group under the official LoCo umbrella group. (Related issue, see below)

Code

n/a at this time

Data preservation and migration

No change from current implementation.

Unresolved issues

• Can we enable automatic creation of mailing list for approved LoCo?

• Can we enable automatic subscription of mailing list for any LoCo?

• Can we enable automatic creation of website for approved LoCo?

• What sort of permission/interface is required for allowing LoCo team email address forwarding?

• Can we create a type of a 'heat map' (i.e. user map) of each Country/State based on Melissa's coloured map which includes identification of approved teams?

• Should we require users of LoCo teams to sign the CoC before they can obtain the features we are recommending in the use cases?

• Today sub-grouping of Launchpad teams is done manually be emailing launchpad-admin or rosetta-admin. This should be automated somehow.

• Do we include linking alias email domains to the launchpad web and/or wiki page for each LoCo team?

  • Use Case: Melissa is a Windows user who meets Dave at a LoCo event. Dave gives Melissa his LoCo email alias of dave@beloco.ubuntu.com. Melissa at home puts http://beloco.ubuntu.com in her email address and lands at the LoCo's homepage.

BoF agenda and discussion

• [wiki:/BOFDetails]

Comments

• A CMS integrated with launchpad would be _really_ cool. Right now, for practical reasons, we have chosen to make the site as static as possible, versus dynamic data on the wiki. Launchpad integration would afford us the best of both worlds here. Less bloat, less maintenance, less vulnerable to failure (volunteer admin), easier to distribute editing work.
• For our volunteer map, launchpad would be a privacy problem. Right now, we collect sensitive data like exact street address, cell phone number, ... I don't feel comfortable entrusting this kind of data to Launchpad as it stands, a closed application controlled by a for profit company. I'm afraid volunteers are just not going to accept this, privacy sensitive as many of them are. Having the foundation in charge of guarding this data might be a nice step, but my gut feeling is that this information should ultimately be under the control of the locoteam itself.

CategorySpec