Differences between revisions 23 and 24
Revision 23 as of 2006-11-09 23:46:54
Size: 10550
Editor: 207
Comment: some comments
Revision 24 as of 2006-11-09 23:50:25
Size: 10403
Editor: 207
Comment: please pay attention on the warning when editing wiki pages!
Deletions are marked like this. Additions are marked like this.
Line 96: Line 96:
---- /!\ '''Edit conflict - other version:''' ----
Line 99: Line 98:
---- /!\ '''Edit conflict - your version:''' ----

---- /!\ '''End of edit conflict''' ----

Unifying LoCo Team Resources w/Launchpad


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.


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


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 go 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 an active member in his LoCo team but has not completed the membership process yet. He is 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@bru.ubuntu-be.org which he then uses on all communications.

  • Melissa is a Windows user who meets Dave at a LoCo event. Dave gives Melissa his LoCo email alias of dave@bru.ubuntu-be.org. Melissa at home puts http://bru.ubuntu-be.org in her browser and lands at the LoCo's homepage.

  • Rich is planning an event for his LoCo team. He heads to his team's Launchpad entry and creates a meeting entry. He posts the meeting specifics. Later that day, Dennis, a member of the same LoCo, updates the meeting agenda with new topics which may also reference a particular specification they are tracking. Belinda, an interested member of the same LoCo, views the LoCo's website and takes note of the meeting particulars so she can attend.


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.


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.


1) Data to store inside Launchpad

  • LoCo team record:

    • LoCo Team flag to signify whether team is LoCo team or not

    • Approved Team Flag to signify whether team is approved or not
    • LoCo team primary contact flag

    • LoCo timezone

    • LoCo Mailing List Information with basic integration (see subpage with details)

    • LoCo Website Information

    • LoCo official IRC channel

    • LoCo Wiki Page

    • LoCo Planet address

    • LoCo Meetings (linkage)

  • Member record:
    • user email alias for approved teams (Related issue, see below)
    • user blog address
    • user Planet subscriptions
    • user mailing list subscriptions
  • [wiki:/lpdetails Details for Launchpad 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)

4) Launchpad will autogenerate a list of teams which can be pasted into the [wiki:LoCoTeamList LoCo Team List] on the wiki. This will allow the community manager to do a frequent refresh of this information keeping it current as team dynamics change.

5) Lauchpad will link meeting information from the meeting subsystem into each LoCo team page.


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?

  • Can we enable automatic creation of a Planet 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?

  • Is it possible to enable RSS/OMPL feeds from Launchpad such that websites can automatically receive feeds from Launchpad using the meeting items described above?

BoF agenda and discussion

  • [wiki:/BOFDetails]


  • 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.
  • Would Launchpad also help with the issue of non-response to requests for mailing lists/other resources? i.e. Joey has been trying to get a mailing list setup with no response under the usual process. Could this new process have some sort of tracking for support issues that continue to go unresolved? (similar to the internal problem tracking ticket system) There needs to be some redundancy in the process so there is not a single point failure when Teams are asking for help.
  • Instead of generating a configuration file for a Planet based on the members of a given LoCo Team (like the current PlanetPlanet configuration file), and then have that file copied/moved to the designated location, we could adopt a system like feedburner. This one single feed could then be used in a local configuration file, and thus avoid the generate/save/copy or move procedure usually used for Planets.

  • I think it'd be better to rewrite item number 4 under the "Implementation" section as a use case, because the generation of the team list in an easily parseable format is not mentioned anywhere.
  • I thought we agreed on first implementing the generation of the planet config file as well as the user maps. My main concern is that we can't promise to implement the mailing lists support any time soon, because we don't yet have the okay for the integration of teams with mailing lists and also because it would require a lot of work, once approved.


LoCoTeamsUDSMVSpecs/UnifyingLoCoTeamResources (last edited 2008-08-06 16:17:56 by localhost)