MotuProcessesSpec

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 either checks the wiki page or gets the 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 MOTU Council (and only informally 'Council Grayskull').

  • The Council will consist of five ubuntu-dev or ubuntu-core-dev members.

  • The Council will deal with organisational problems specific to the MOTU community. If a final agreement can not be reached, the TB is consulted in technical matters and the CC concerning social matters.
    Also, if needed, MOTU related matters can go to the CC and TB directly, bypassing the MOTU council.

  • The meetings will be held every three 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 Council will create wiki pages for easier reference.
  • 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 MOTU Council mailing list and CC his sponsors.
    • The council will have two weeks of time to check the references and reply back.
      • The applicant is encouraged to mention packages she/he maintains or specific uploads that were done quite well.
      • The Council will check Launchpad's /+packages page, talk to select team members and go with the information collected that way.

      • General guide lines for membership approval are to be found at UbuntuDevelopers.

    • The outcome of this will be presented to the TB, who will have the final say. The exchange with the TB happens via mail.

Decisions which are deferred to the first MOTU Council 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'? Inactivity is identified by checking the -changes list and checking their /+karma page.

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.

Nomination process and term length:

  • The TB nominates the MC members and the MOTUs will confirm. The nominees for the first MOTU Council are

    • Andrew Mitchell (ajmitch)

    • Daniel T Chen (crimsun)

    • Dainel Holbach (dholbach)

    • Gauvain Pocentek (gpocentek)

    • Stefan Potyra (sistpoty)

  • A term length of 2 years was decided and two of the nominees start off with one year term, namely crimsun and gpocentek. This was decided, so that an initial rolling is introduced into the process. (Their membership can be renewed.)

Documentation and Reporting:

  • The MC will report to the TB in form of

Comments

[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] [dholbach: I'm not quite sure I understand your request.]

CategoryArchive
CategorySpec

MotuProcessesSpec (last edited 2009-01-26 09:18:30 by i59F70AD9)