EasierMotuing

Differences between revisions 4 and 5
⇤ ← Revision 4 as of 2006-06-20 10:51:44 →
Size: 6254
Editor: ALagny-109-1-10-87
Comment:
← Revision 5 as of 2006-06-20 12:37:23 → ⇥
Size: 7101
Editor: ALagny-109-1-10-42
Comment:
Deletions are marked like this. Additions are marked like this.
Line 113: Line 113:
=== Webpages ===

 * ubuntu.com -> community -> contribute (universe) needs changing: it currently points to http://wiki.ubuntu.com/MOTU/Teams, but should point to http://wiki.ubuntu.com/MOTU
 * the MOTU page should invite people to use mailing lists and irc
Line 115: Line 121:
We will emphasize the MOTU Reviewers team in Launchpad by
 * advertising it on the mailing list,
 * document its use on http://wiki.ubuntu.com/MOTU/Processes - this will include information on how to create a debdif and proper changelog.
Line 116: Line 125:
 * Make more use of it
 * Advertise it
 * Document it
  * How to make a debdiff & changelog entry
 * Get more people involved in it
 * DO REVIEWING WORK ;) 		We will try to get more people involved in it to make sure the TODO list of the `motureviewers` team is always cleaned up.
Line 123: Line 127:
=== REVU interim solution ===

We will make allowances to let good motu wannabes to 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.

Summary

The specifications outlines processes and points of action to make "getting involved" easier.

Rationale

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.

Scope

The scope of this specification is improvements we can make to

  • attract more MOTU hopefuls,
  • make it easier for them to find their place,
  • keep them interested and
  • find sustainable processes which make all of this as easy as possible.

Design

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)

Implementation

Wiki

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 to 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 announce on ubuntu-motu@lists.ubuntu.com

We will try to have a session every two to three weeks. Experienced contributors will be asked to do 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 those IRC sessions will be stored on the wiki and used to refine them in 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, as it is easier for complete newbies to start off.

Mentoring

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 on 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 a '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 broadcasted on the mailing list as well.

Example Packages

Provide a list of excellent documented and prepared example source packages. 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, which ppl would/will package. These packages should be from a variety of categories, e.g. GNOME, KDE, games, python.

Webpages

MOTU Reviewers team

We will emphasize the MOTU Reviewers team in Launchpad by

We will try to get more people involved in it 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 to 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

CategorySpec

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