This specification outlines processes and points of action to make "getting involved" easier.


The MOTU activities should

  • be more inviting,
  • try to target more of the interested and technically apt users and
  • make it easy for them to get involved and to find their place in the community.

Use cases

Martin joins the channel #ubuntu-motu and tries to figure out how to help out. Somebody in the channel makes use of the bot, which will provide Martin with a nice text and a link to the wiki.

Matt wants to help out as well and asks on the mailing list. Somebody points him to a list of real easy tasks and instructions how to start on those.

Mark is pointed to MOTU Documentation and is able to rebuild a package by following instructions on an example.

Matthew knows quite a bit about packaging, but has no idea how the build daemons work. After asking for a MOTU School session about the archive and build sessions he knows a great deal more.

Bjorn wants to find out about MOTU processes. He is pointed to http://wiki.ubuntu.com/MOTU/Processes and finds everything he needs.


The changes involve:

  • the wiki
  • MOTU school sessions
  • channel bot
  • a task list
  • small changes to REVU (as an interim solution until REVU2 is there)


  1. The wiki will be categorized and unnecessary and stale pages will be removed.
  2. New MOTU school will be reopened, developers will be asked to give sessions, interested MOTU wannabes can request sessions.
  3. We will implement "Initial Mentoring". Shy contributors will have the possibility to mail volunteering MOTUs and developers who will help them until they're ready to communicate via mailing lists and irc channels.
  4. MOTU/TODO will be kept recent and we will implement policies to ensure that the instructions to help out are accurate and easy to follow.

  5. We will revive our mailing list and encourage new MOTUs to use it for their questions, plans and ideas.
  6. We are going to keep a list of perfect reference packages of different sections using a variety of packaging styles.
  7. Some web pages will need revamping to avoid confusion.
  8. The MOTU reviewers team will be a central institution and part of the process for getting uploads sponsored.
  9. REVU will receive small changes to make reviewing of new packages easier. This is part of an interim solution until REVU2 is actively developed.



We are going to divide the content within CategoryMOTU into the following namespaces:

  • MOTU/Documentation
  • MOTU/Events
  • MOTU/Mentors
  • MOTU/Processes
  • MOTU/School

Apart from that we are going to remove all unneeded pages or make them links to the appropriate chapters in the Packaging Guide.

The MOTU school

The MOTU team is going to revive the MOTU school and feature short sessions with Ubuntu developers every two to three weeks. The first set of topics will include:

  • "How do I merge changes in Debian?"
    • it will be important to do this session in the beginning of each release cycle.
  • "How do I update a package properly?"
  • "What do I have to do, if I maintain a package?"
  • "Cool things to do with python-apt."
  • "Soyuz and all that Jazz"

MOTU/School/Requests will be a list where people can add topics of their choice and mention problems they face. The page will be announced on ubuntu-motu@lists.ubuntu.com

We will try to have a session every two to three weeks. Experienced contributors will be asked to host brief sessions (20 minutes plus working on live examples, answering questions). These sessions will be announced regularly on the Fridge, our mailing list and MOTU/School/Sessions. It would be nice to have blog posts about how the sessions went.

The logs of these IRC sessions will be stored on the wiki and refined into wiki docs, which may find their way into the Packaging Guide. We will also try to encourage MOTUs and developers to repeat the sessions in their own language to reach out to other communities.

Using real-live examples will be essential, so that it will be easier for complete newbies to start off.


We will create the MOTU/Mentors namespace on the wiki and have a list of people who are willing to help interested contributors, who are still very new to Ubuntu packaging.

A mentor will answer the first questions by mail. This will make the whole experience less intimidating and, as lots of questions might be asked over and over again, we will compile a Mentoring FAQ which might serve as canned responses.

We will gradually try to push people to use our mailing list and our IRC channel, as communication in public is more effective and not lost as easily.

This list will include the languages people speak and their areas of expertise to reach out to other communities.

List of possible mentors? List of people and their areas of expertise? The MOTU mailing list is not really an option for shy people, so more personal contact in the beginning would be preferable. Advertise a mentor page on the forums (if people are interested in helping out).

Task list

As an answer to the common question "What can I do?" we will clean up our TODO page, make it more recent and:

  • add Transition lists, which will properly document
    • WHY a transition or change happens,
    • HOW it is done,
    • HOW to double-check the fix has happened,
    • HOW to get the fix reviewed & uploaded

  • assign bugs to an 'easy-to-fix' team (YES, we can pick another name.) (KDE uses JJ in the title for Junior Jobs)
    • Investigate the GNOME LOVE project
    • Testing updates that may be in Debian - dapper has had some easy fixes that we missed
  • easy merges

We need to review this list after each particular freeze in the release schedule.

Mailing list

The MOTU team will make more use of the mailing list and we will add points in our Documentation to make sure that decisions and changes we've decided are always broadcast on the mailing list as well.

Example Packages

We are going to provide a list of excellent documented and prepared example source packages. We would like to have packages, which are not as trivial as gnu/hello, but show principles of debhelper and cdbs, and how these can be applied to other new software. These packages should be from a variety of categories, e.g. GNOME, KDE, games, python.


MOTU Reviewers team

We will emphasize the MOTU Reviewers team in Launchpad by

We will try to get more people involved in the team to make sure the TODO list of the motureviewers team is always cleaned up.

REVU interim solution

We will make allowances to let good motu wannabes comment on packages on REVU as well. That will make it easier for MOTUs to find packages that might deserve a "GO AHEAD" already.

REVU hackers will hopefully add a "peer review done" flag, to make spotting them easier.

We might introduce a change to also show the package description.

Outstanding issues

General changes to packages (not just for universe) should be described in https://wiki.ubuntu.com/UbuntuPackagingChanges, described in the spec https://wiki.ubuntu.com/UbuntuPackagingChangesSpec.


Spec/EasierMotuing (last edited 2009-01-26 09:18:49 by i59F70AD9)