Future of MOTU

[Emmet Hikory]

Fellow MOTU,

    During the Jaunty UDS, discussions of Archive Reorganisation (0)
indicated that MOTU would be no more, and all of us should have
received a request for feedback as to how we wished to proceed with
our individual roles in Ubuntu Development.  This work was met with
wide apathy, and some confusion.  At the Karmic UDS, discussion of the
future of maintenance of those packages not belonging to specific
teams was discussed, with the conclusion that it would be sensible to
maintain a development team dedicated to the maintenance of these
packages, resulting in a specification (1) that has now been approved
by the Developer Membership Board (2) and Technical Board (3).  As a
result, we now have a new mission, summarised as:

 * Maintain packages that do not belong in any packagesets (4)
 * Provide guidance and training for new generalist developers
 * Extended Quality Assurance functions (FTBFS, NBS, UEHS, etc.)

    There remain several areas for action in order to fully realise
the new MOTU role, as follows:

A) Leadership

    We have historically been broadly without hierarchy, nominating
and recognising some of our number as leaders (5) as a result of their
continuing efforts in some area that directly improves the health of
the team.  On quick review, our leadership page is out of date, and
many of our leadership roles no longer have clear meaning as
ArchiveReorganisation continues.  While each item deserves discussion,
I'd like to suggest the following:

i) Close down MOTU School (6) and merge historical texts, requests,
etc. with the Packaging Training effort (7)  All credit to James, the
current Dean, but I believe the time has come to end the separation in
this area.

ii) Coordinate with all the other Ubuntu Developer Teams to set up a
distribution-wide REVU Coordination team, with representatatives from
each development group helping to ensure that packages of interest to
each area are well tracked, and REVU again becomes considered a useful
tool.  I'd like to call on the REVU Hackers to support this team,
potentially extending REVU to better support tracking of "claimed" vs.
"unclaimed" packages, etc.  The current tags functionality may be
enough, but it may not.

iii) MOTU SWAT needs help, especially as it moves from "universe" to
"unseeded packages".  I believe that extended discussion is worthwhile
between the MOTU SWAT team and the Ubuntu Security team to determine
if all security efforts could follow a standardised process and be
handled by a single extended team (with some potential for separation
within the team to support embargoed information, disclosure
requirements, etc.).  If MOTU SWAT is to remain separate, some work
will need to be done on the tools to help better track what packages
need attention and when.

iv) Our Mentoring efforts (8) have extended beyond a single Mentoring
Facilitator.  I'm unsure of the current state of this effort, but I'd
think that at least the Junior Mentoring program ought be a single
shared program for all development teams, with only the Senior
Mentoring program preserved as part of MOTU efforts.

v) I think we still benefit from having a Launchpad Liaison team, but
I suspect we'd benefit more with some more visibility into LP
schedules, and some bug tracking.  I'd like to see this team try to
expose activity in more detail, or seek fresh membership who would
volunteer to do so.

vi) As long as the incumbent is willing to serve, I think we should
continue with the current Canonical Liaison.  Of all the areas in MOTU
Leadership, I've heard the least complaints about Daniel in this role.

vii) The current MOTU Council is unquorate, and unable to take any
action.  I believe that the current members should be released from
their responsibility until we have some consensus on how to deal with
Governance (B).

viii) There is current activity merging the MOTU Release Managers with
the Ubuntu Release team.  Much credit to the good work done in the
past, but I think we will benefit more from a single coherent team
than having a separate set of delegates, such that Ubuntu Release
members drawn from MOTU ought not be seen as having any special role
with MOTU, but rather a special role within the whole of Ubuntu.

ix) The MOTU Stable Release Update Supervisors is now an obsolete
team, there being an integrated process for stable release updates
distribution-wide.  Unless there are objections, I suggest we drop
this team from our leadership page.

x) Luke and I haven't been doing as good a job with the Sponsors Queue
as we'd like, and Daniel's new package-set based sponsoring overview
(9) is vastly superior at identifying the relationships between
packages and packagesets.  I believe this team can be retired once the
sponsorship team merge(10) is complete.  Thos interested in improving
the discoverability of sponsoring opportunities are encouraged to help
Daniel improve the tool.

    Also, if anyone knows of other areas in which individual MOTU have
shown leadership, or are taking charge of some aspect of how we do
things, please nominate them as leaders.  It is through recognition
that we can best reward each other, and we all benefit from happy
motivated leaders helping us to accomplish our goals.

B) Governance

    MOTU has historically been governed by a set of bodies with full
separation of powers: specifically the Leaders, empowered to act
unless constrained by policy or dispute, the MOTU Meeting, able to set
policy and delegate powers from individual MOTU to specific groups,
but unable to take direct action (and specifically not identified with
individuals), and the MOTU Council, able to approve new MOTU, resolve
disputes, and adjudicate issues unresolved by MOTU Meeting.  As the
team is being redefined, we should examine this governance structure
to determine if it continues to meet our needs, and what modifications
seem suitable to ensure the health of the team in the future.

    We have also been explicity requested by both the Developer
Membership Board and the Technical Board to discuss the future of MOTU
Council on the motu-council mailing list.  Let's start this discussion
soonest.

    My personal feeling is that the model has become overly weighted
due to procedural requirements and confusion, and while strong in
intent, needs overhaul to meet our needs in the future.  While all
sorts of models should be available for discussion, I'd like to
suggest the following:

i) Retain MOTU Leaders as those who we recognise as having special
drive, expertise, and activity in specific areas, and continue to
grant these MOTU special authority to set guidelines and best
practices related to their area of expertise.  I think this has worked
in the past, and provides a dynamic force for helping us to know how
to accomplish many of our goals.  I'd like to add an expectation that
those MOTU recognised as Leaders report regularly (say monthly) to the
rest of MOTU on their activities and plans, firstly to encourage other
MOTU to participate in that area (and provide for backup/turnover as
individual interests shift), and secondly as a way to help identify
when Leaders are not making progress, and may need assistance or
support in their sphere of operations.

ii) Revive the MOTU Meetings on a regular rotating schedule (I like
22:00, 6:00, and 14:00 UTC with a meeting every week, rotating over
three weeks).  While I'd like to retain the power of MOTU Meeting to
establish policy, with Archive Reorganisation, there is much less
policy that is necessarily MOTU-specific, and we would likely benefit
from use of the meeting to also discuss other areas (transitions, QA
efforts, sets of packages with lots of bugs, requests for help with
specific things, blocking issues, coordination with distribution-wide
teams, etc.).  To facilitate this, I'd like to suggest that not all
agenda items need the full announce/meet/shepard process, but rather
that the sheparding process only be used where policy is specifically
being adjusted (and only in cases where policy is entirely specific to
MOTU: many policy issues are better brought to the Technical Board).
A regular meeting with publised minutes also serves to keep all MOTU
informed of activities, even when they may not be able to track IRC
closely or follow various bug reports.

iii) Establish a MOTU Council with explicit responsibility to oversee
MOTU Leaders, facilitate MOTU Meeting, and resolve disputes within
MOTU.  I would also expect this team to coordinate with the Community
Council, Developer Membership Board, and Technical Board for any cases
where there is confusion or conflict between MOTU policies or
practices and distribution-wide policies and practies, with explicit
mandate to seek alignment of any MOTU policies or procedures with
distribution-wide policies and procedures.  I would like to explicity
restrict this council from setting policies, guidelines, or best
practices directly, excepting that individual members may have
authority to do so as MOTU Leaders, participants in MOTU Meeting, as
individual MOTU, or due to other distribution-wide roles.

iv) I feel very strongly that individual MOTU should be fuly empowered
to take action, and that any rights, privileges, or authorities not
explicity granted otherwise within MOTU, or reserved distribution-wide
should be retained by the several MOTU acting individually or
collectively.  In those cases where there is friction or confusion,
I'd rather see action taken and dispute resolved by Meeting or
Council, rather than inaction whilst waiting for a potential future
consensus.

C) Communication

    There's been less and less traffic on the MOTU Mailing List, and,
to my impression, less coordination discussion on the IRC channel (it
seems largely devoted to training and chatting).  I feel that in order
to maintain a sense of "team" and in order to best get things done, we
would do well to better communicate with each other about what we are
doing, and what we plan to do.  So, please speak up.  Let others know
what you are doing, what you think, or if you need help, or if you're
bored and have time to help someone else.

    Further, as our new role has been defined in parallel to Debian
QA, let's put more effort into communicating with Debian QA, and
coordinating our efforts.  As MOTU, we do a lot of work on packages
that are only maintained by Debian QA (as they don't have proper
maintainers in Debian, so bugs tend to accumulate).  To avoid
duplication of effort, we should be aggressively seeking to keep these
packages in good shape *also* in Debian, just to avoid the effort of
merges (as there are few packages in this category that truly require
Ubuntu variation).

D) Coherance

    In the past, some people viewed MOTU as a "first step" towards
getting involved in another area of Ubuntu Development.  Others with
narrower interests would join MOTU as the only option to be able to
work on e.g. scientific packages.  With Archive Reorganisation, we now
have significantly extended facilities to provide for flexible access
control.  All of you should have received a query asking what sort of
Ubuntu Developer you were interested in being in the absence of MOTU.
To help the coherence of MOTU as a team, I'd like to request that
those of you with narrower specific interests request the
identification of packagesets to cover your interests: this may be of
especial interest to those teams who coordinate closely with Debian
(e.g. Pythonistas or Games).  Where there exist teams with narrow
interests, let's get package sets established.  Please sign up to be
as many types of Developer as you'd wish, and identify all the
packages that *do* have teams that care for them.  Those of you who
wished to focus on specific flavours, please seek to join (or define)
flavour-specific teams.  Those of you who wished to become core-dev,
please apply.  Those of who who have upload access to all your
packages of interest by other means, please consider whether you wish
to continue as MOTU under the new definition.

    Let's focus on identifying the true set of packages that *need*
MOTU attention (due to not already having a maintenance team), and
helping to identify which of us have a real interest in working to
improve those packages.  With this increased focus, we should be able
to do a much better job of keeping the entirety of the archive in good
shape for each release, and ensure that Ubuntu remains an incredibly
flexible, dynamic, rich, and powerful software collection into the
future.

    Thanks for reading the entirety of this: please criticise,
commend, amend, adjust, and discuss: let's make MOTU strong again!

0: https://wiki.ubuntu.com/ArchiveReorganisation
1: https://wiki.ubuntu.com/Specs/LucidMOTU
2: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2010-February/000672.html
3: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2010-February/000673.html
4: https://wiki.ubuntu.com/ArchiveReorganisation/Permissions#Nomenclature
5: https://wiki.ubuntu.com/MOTU/Leaders
6: https://wiki.ubuntu.com/MOTU/School
7: https://wiki.ubuntu.com/Packaging/Training
8: https://wiki.ubuntu.com/MOTU/Mentoring
9: http://qa.ubuntu.com/reports/sponsoring/
10: https://lists.ubuntu.com/archives/ubuntu-devel/2010-February/030194.html

-- 
Emmet HIKORY