ServerTaskForcesSpec

Summary

The creation of Ubuntu Server task forces around a given common interest should help crystallize our potential contributors into real server stack owners.

Release Note

A clear governance model is now proposed for those that want to adopt, maintain and own specific groups of packages in Ubuntu Server.

Rationale

The classic recipes to get community involvement don't seem to work well with Ubuntu Server (see low participation in the Server Papercuts effort). Our potential developer community is mostly professionals using Ubuntu Server for a living, with an interest in specific stacks. We should empower people with common interests around a specific server stack to crystallize into a group that could ultimately maintain a package set. The lack of structure around the current subgroups prevented so far proper motivation/information/organization.

User stories

As an Ubuntu enthusiast working in a company selling telephony services, I would like to help in making it better. With the server task forces effort (discovered while looking up Ubuntu Server pages), I now have a clear path to form a group that can ultimately own this stack and move it in the right direction.

As an university student, I see potential for starting a consulting business around Clustering. With the help of someone on IRC pointing me to the documentation, I joined the existing Cluster Stack task force and can now learn by helping triaging bugs.

As an upstream likewise-open developer, I care about the state of the package in Ubuntu. I joined the Windows integration task force (responsible for the package set in which likewise-open lives) and can now directly help in fixing it.

As a Canonical Server developer, I have some personal interest in good directory integration. I spotted some interested drive-by triagers and proposed that we form together a new Server task force around directory services.

Assumptions

Some form of control and ownership will be delegated to the task force, which in return will have to report on policy decisions and specs progress.

Design

Naming

We need a catchy and cool name, maybe "server task forces" is not that sexy. Proposed alternate names are "subcommunities", "communities of practice", "stack maintainers". Please sed s "task forces" in the text below wit the chosen term, if needed.

Governance model

Creation

The task force should be founded as an LP group. It should consist of more than one person. Its application to become a formal server task force should include a mission statement, the list of packages covered, and at least one blueprint/spec with plans for the current (or next) development cycle. The admin(s) of the group will be supposed to be the primary point of contact. Application will be reviewed during the Server team weekly IRC meeting, and if accepted, the task force will be listed in the official Server task forces directory wikipage.

Task force rights

The task force can shape the future state of the packages that are part of it. Its members define the design and implementation details of the blueprints/specs around those packages. The specs are reviewed by the Server engineering manager and accepted or denied for the current development cycle, like for any other specs.

Upload rights are not directly linked to task force participation: they are reviewed and granted by the Developer Membership Board. However, being part of a task force that cares about a particular package set is obviously recommended to get said upload rights to it Smile :)

Task force duties

The task force should report progress regularly during the weekly server IRC meeting, and update the status of their specs so that it's easy for anyone to follow what they are up to. It should raise any significant policy decision in an ubuntu-server or ubuntu-devel ML thread to give the rest of the community of chance of commenting.

Publicity

When the governance model is ready, we need to make a lot of noise about it to (1) move existing groups into the new model and (2) make sure every other potential candidate knows about it. This includes (but is not limited to) noticing regular bug triagers on some specific specs and encouraging them to form a proper group.

Example task forces

Existing and active
  • Documentation
  • Mail stack
  • Cluster stack

Good candidates
  • Telephony stack (asterisk and friends) -- existing and passive (~ubuntu-voip)
  • Directory stack (openldap, dit, nss-ldap, etc.) -- some interest from sommer and Nathan Stratton Treadway
  • Windows integration (samba, likewise-open, winbind...) -- some interest from likewise-open upstream

Implementation

See ubuntutheproject-community-n-server whiteboard for details.

Test/Demo Plan

This is not a feature so there is no test plan. The project is completed when all the process is in place. Success is measurable by the number of task forces actually created.

Unresolved issues

None.

BoF agenda and discussion

  • One team, which has stagnated the last two releases is ~ubuntu-voip, which seems to fulfill the first use case. -- DaveWalker

    • Added
  • Perhaps more consideration could be put around delegation of PPU's to a subset of people. One model that could work is $stackname as perhaps an open team, or moderated with low barrier of entry to help identify those with interest in that stack. Additionally another team $(stackname)-dev which members can aspire to be part of, which has PPU access for the particular stack. -- DaveWalker

    • Not sure DMB would delegate the ability to give package set upload rights to $(stackname)-dev admins... but the subject of upload rights is disconnected from task forces. They are granted to a team or an individual based on meritocracy and trust, using well-proven mechanisms, that this spec is not planning on changing.


CategorySpec

ServerTaskForcesSpec (last edited 2010-11-02 12:47:21 by lns-bzn-48f-81-56-218-246)