MotuProcessesSpec

Revision 7 as of 2006-11-30 10:33:20

Clear message

Specification

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. [pitti: why wait until a meeting? if there is a summary report anyway, why not put it into the wiki, similar to the distro team meeting reports?]

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 MOTU Council (Informally 'Council Grayskull'). [pitti: /me hates heavy metal music; seriously, this is intimidating]

  • The Council will consist of five ubuntu-dev or ubuntu-core-dev members. [pitti: how are they determined? election from CC?]

  • The Council will deal with problems in the MOTU community. [pitti: I guess this should be a bit more precise, the MC should certainly not deal with *all* problems? also, apparently they deal with both social and technical questions? decision of technical questions seems to conflict with the responsibility of TB?]

  • 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. [pitti: that's a lot of reporting; if it's at the fridge or wiki, then UWN should just link to it and interested CC/TB members can always read it there; or was there a specific reason to mention it there as well?]

  • 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 [pitti: argh] mailing list and CC his sponsors.

    • The Grayskull Council will have two weeks of time to check the references and reply back. [pitti: whose responsibility is it to collect references? any standard format/place?]

    • 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'? [pitti: probably a good idea, after a year there might be so many changes]

[pitti: I'd prefer having these decisions codified in the spec for easier reference, and as a 'foundation document', but I'm fine with the deferring, too]

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.

[pitti: implementation does not cover how inactive members are identified; my gut feeling is that this should be based on our Karma system? what's the process?]

[:CategoryMOTU]BR [:CategorySpec]