EasierMotuing

Differences between revisions 2 and 3
Revision 2 as of 2006-06-19 13:56:15
Size: 4862
Editor: ALagny-109-1-2-23
Comment:
Revision 3 as of 2006-06-19 15:00:34
Size: 5422
Editor: ALagny-109-1-2-23
Comment:
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:
 * '''Packages affected''':
Line 8: Line 7:
In the specification process we'd like to figure out problems we currently face in the MOTU world. Identifying bottlenecks and off-putting processes and areas lacking involvement. The specifications outlines processes and points of action to make "getting involved" easier.
Line 25: Line 24:
Sébastien found five different packaging guides which deal with things differently in most occasions. Needless to say: he's quite confused.
Line 26: Line 27:

Bjorn wants to find out about MOTU processes. He finds some pages scattered across the wiki. He hears about some other processes on the IRC channel and finds some others answered in mailing list threads.
Line 42: Line 45:
  * NEW queue
Line 44: Line 48:
 * NEW queues (source and binary) not shown on Launchpad (they are now: https://launchpad.net/distros/ubuntu/edgy/+queue)   * MOTU report? UWN?
Line 46: Line 50:
== Scope ==
Line 47: Line 52:
== 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.
Line 51: Line 60:
The changes are spread across:
 * the wiki:
  * categorization to the wiki
  * pruning of unneeded documents on the wiki
 * MOTU school sessions
 *
 

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. Nobody answers him, everybody is busy with their own packages or geek discussions.

Matt wants to help out as well and asks on the mailing list. Somebody replies "Look at Universe bugs."

Mark fought his way through documentation, but tries to find "Live Examples" and how to actually get things done.

Sébastien found five different packaging guides which deal with things differently in most occasions. Needless to say: he's quite confused.

Matthew knows quite a bit about packaging, but has no idea, how the build daemons work, where and why to get a key signed. Apart from that he doesn't know the people involved in Ubuntu and those with key roles.

Bjorn wants to find out about MOTU processes. He finds some pages scattered across the wiki. He hears about some other processes on the IRC channel and finds some others answered in mailing list threads.

Problems we identified

  • Task list
    • answers are "Go on the candidates list!", "Go on universe bugs list!"
  • documentation
    • packaging guide vs wiki vs debian packaging guide vs kubuntu packaging guide
    • wiki is confusing and ambiguous
  • "real" newbies
    • nobody has time to answer questions
  • clarify processes
    • ownership vs team approach
    • release schedule
    • uploading
    • revu
    • membership
    • NEW queue
  • recognition
    • LP karma would do nicely, but requires tight integration with LP, I guess.
    • MOTU report? UWN?

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 are spread across:

  • the wiki:
    • categorization to the wiki
    • pruning of unneeded documents on the wiki
  • MOTU school sessions

Implementation

The MOTU school

One key to some of the problems would be to revive the MOTU school again and feature short sessions with Ubuntu developers every now and then, possible topics could be:

  • "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"
  • ...

All topics suitable for an MOTU School session get collected on the wiki: MOTU/School/Sessions (<--fixme) Everyone is invited to propose new topics, 'teachers' may claim a session by putting their name on that wiki page.

We can write documentation from the sessions. It should be easy to find people to give 20 minute talks and answer questions or showcase examples afterwards. If we demo with real-live examples (real-live packages), it should even be easier to get people started and show them how to "get things done" easily.

It should not contain only in-depth topics but things to start with.

Wiki

Divide content in to Namespaces:

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

Mentoring

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).

http://fedoraproject.org/wiki/Mentors - an attempt at a similar thing.

How do I get involved?

  • Transition lists
    • [:PackagingHints] is a spec which talks about properly documenting:

      • 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

Revive mailing list

At the moment the mailing list is not very busy. At some stage people should feel comfortable enough to just ask on the mailing list (where it's public and persistent - as opposed to IRC or private communication).

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.

MOTU Reviewers team

  • 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 Wink ;)

Outstanding issues

BoF agenda and discussion


CategorySpec

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