Specification

• Launchpad Entry: https://features.launchpad.net/distros/ubuntu/+spec/motu

• Created: Mon, 06 Nov 2006 11:43:26 -0800 by DanielHolbach

• Contributors: DanielHolbach

Summary

The MOTU have come together as a vital part of the Ubuntu community, playing a tremendous role in making Ubuntu more broadly useful and as a place for developers to demonstrate their skills. We will review the organisation and processes around the MOTU and see what improvements we can make.

Rationale

Some processes proved to be bottlenecks which slowed down the progress of MOTU. We will revisit processes we decided on in the past and the advent of a MOTU Council will improve the overall speed and reduce the number of stages a decision has to go through.

Use cases

After having worked with the MOTUs for a while, Mark is encouraged by MOTUs to join the forces. He writes a mail to the council mailing list and gets a decision within two weeks.

James wants to get involved and is told to look at the MOTU/TODO wiki page. He finds some easy tasks on there and is able to help out, even with what he thinks is little knowledge.

Daniel looks at the MOTU members page and is able to identify active members easily.

Matt wants to know what the MOTU council did in the last meeting and who they approved to become MOTU. He gets a full report in the TB meeting.

Scope

The process changes involve small tweakings and reconsiderations, but more importantly introduce the MOTU council, which will be the central place for decision making and improve MOTU management.

Design

The MOTU council will help to find consensus and have a final say in conflicts. It will also take care of approval of new MOTUs. Apart from that it will try to organise the MOTU efforts and make it easy for everybody to concentrate on what they want to do.

The other process changes involve

• revisiting the policy of NEW packages,
• introducing a process to identify inactive MOTUs,
• adding a document about the 'hard freeze' process,
• reporting events in the MOTU team to the CC, TB and UWN regularly,
• updating the MOTU/TODO during every MOTU Council meeting.

Implementation

The implementation details regarding the MOTU council have to be approved by the CC and TB meeting. The outcome of the sessions is lined out here:

• The MOTU Council will be called Council Grayskull.

• The Council will consist of five ubuntu-dev or ubuntu-core-dev members.
• The Council will deal with problems in the MOTU community.
• The meetings will be held every two weeks.
• One permanent item of the meeting agenda will be to review the MOTU/TODO page.
• The Council will report the outcome of meetings and interesting developments to the CC and TB, also to the UWN or Fridge.
• The new membership process will work as follows:
  • After working a while with the MOTU community a MOTU hopeful will be encouraged to become MOTU by his sponsors or other members of the team.
  • The MOTU hopeful will write a mail to the public Grayskull mailing list and CC his sponsors.
  • The Grayskull Council will have two weeks of time to check the references and reply back.
  • The outcome of this will be presented to the TB, who will have the final say.

Decisions which are deferred to the first Council Grayskull meeting are:

• Will one ACK suffice for getting a NEW package approved?
• Will we mail MOTUs after one year of inactivity and probably mark their status as 'deactivated'?

Clear action points are:

• Write down the process for 'hard freeze' approval.
• Improve the documentation of freezes to be less intimidating.
• Draft the processes to announce them on the mailing list before a decision will be reached in the meeting.

[:CategoryMOTU]BR [:CategorySpec]