CommunityRoleInDistro

Status

• Created: 2005-04-25 by JaneW

• Priority: LowPriority

• People: DanielHolbachLead, JaneSilberSecond

• Contributors: JaneW, AnkurKotwal, AndrewMitchell

• Interested: ColinCharles

• Status: DistroSpecification, ApprovedSpecification

• Malone Bug:
• Packages:
• Depends:
• Dependents:
  1. AustralianTeam/Meetings/2006May02 (meeting.log.html)
  2. OklahomaTeam/foo/testProjectsIdeas (LinuxPresentationDraft001.odt)
  3. UbuntuDownUnder/BOFs/CommunityRoleInDistro

• UduSessions:

Introduction

We have numerous mechanisms to solicit and facilitate community involvement. These include:

• LoCo teams for local advocacy, mentoring, and community building

• MOTU teams for developers
• Documentation teams for people who want to share their knowledge of the existing systems.

These efforts are well organized and seem to be effective, but most perpetuate a barrier to non-developers, non-developers contributing to the distribution itself (although they obviously contribute in a meaningful way elsewhere). This specification addresses the role the community can play with getting involved with the Ubuntu distribution itself, e.g., in the specification process and in prioritizing features, and saying what they want most/first.

Rationale

This effort will allow the non-developer portion of the community (and developers too) to be heard, and to ensure that the most wanted items can be focused on first.

Scope and Use Cases

• Jeff is a fairly fresh Ubuntu User but feels that Rhythmbox needs slight enhancements. He's willing to offer some time, but doesn't know how to get in touch with those "hardcore developers".
• Colin now works some time with Ubuntu and has this exciting new idea about getting people from his University involved, but has no idea who to contact to have it even have bigger impact.

Implementation Plan

We want to address three areas we recognized to be problematic:

1. People want to share their ideas, give feedback

   • We already provide a wiki page (http://wiki.ubuntu.com/IdeaPool) to encourage this, but it hasn't received recent attention.

   • The page needs to be reorganized and potentially split into multiple pages.
   • The page should be structured in a way that encourages succinct descriptions of the idea, and does not encourage bug reports or lengthy discussion threads. If something merits discussion that should happen on a mailing list and be summarized on the wiki, rather than having the discussion take place on the wiki.
   • The reorganization of the page isn't enough. We should require the development teams to at least subscribe to the relevant pages. A response on each item isn't practical, as many suggestions may simply distract from current priorities or have been addressed, but knowing that the team is subscribed at least provides a mechanism to know that someone at least will read the page and respond when appropriate.
2. People want to get involved

   • The "Participate" page has been re-written and is a vast improvement. However, it still needs more visibility on the main page (http://www.ubuntu.com) and needs links on top of it which refer to the labels of the sections below

3. People want to write a specification and really make it happen
   • We should formalize the specification process used at Ubuntu Down Under, announce it and make it available to the public. Formalizing the process involves
     • clean up the tags used and create a clearer workflow

     • work out a final SpecTemplate and SpecProcess

     • as with the Idea Pool, some one from the distro team should subscribe to a page which lists Incoming Specs so that they can be reviewed and considered
     • if appropriate, the distro team should get the Spec writers in touch with people they could ask or work with

User Interface Requirements

Outstanding Issues

UDU BOF Agenda

• distinguish different ways of contributing / participating in decision-making
• make a clear statement to the effect that each point of decision needs a proper contact to make it more likely to get included
  • have a "table of contacts" (showing the responsibilities, preferred team mailing lists) to streamline inclusion of ideas

• divide the IdeaPool up into more different task/team-based ideapool-pages

• inform community about interesting changes in all the different teams to let them participate, make them feel involved

  • big implementation plan target; maybe make it part of a policy or at least a part of a "team howto"

• make the SpecTemplate publicly available to encourage community-driven initiatives

---

CategoryUdu CategorySpec