Future of MOTU

[Richard JOHNSON]

On Mon, Feb 22, 2010 at 12:53:09PM +0900, Emmet Hikory wrote:
> Fellow MOTU,
[...]
>     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.

+1. I think this should have been done back in April 2009 when the
Packaging Training effort began, as I noticed a few people back then were a
little confused on what the difference was.

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

Small teams, or smaller teams, such as Kubuntu, Edubuntu, and Xubuntu, this
is quite easy to do. With Kubuntu, we typically upload to REVU, and head
straight to #kubuntu-devel and let everyone know a package needs to be
reviewed. That is how we are pretty quick with it.

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

Could some of the current SWAT members add their voices to this one? I
would like to hear feedback from you all, since this is an area that I
didn't follow closely.

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

+1. I would like to see the dev teams of Kubuntu, Xubuntu, and Edubuntu
help out here as well. Kubuntu in the past has done a decent job, but I
will admit it hasn't been the easiest to get a mentor. This is something I
can bring up with them and see if we can implement a Kubuntu mentorship or
something.

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

Is this a team or a single person? I know in the past Jordan was LPL, then
he handed it over to Reinhard, who then handed it over to both William
Grant and Morten Kjeldgaard last year. William and Morten, is being the
current LPL's a busy task these days? I would like to hear more on this
before deciding on if a team is needed or a LPL at that.

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

Maybe we should start complaining more about Daniel :) +1 though, Daniel is
easy to work with in this position and usually fairly easy to get in touch
with, unless of course he is out walking the dogs :)

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

:(  but I agree. It was a blast serving on the council and working with
everyone, and it was an opportunity I am glad to have been involved with.

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

+1. What about the smaller teams, and I will use Kubuntu once again since
that is where I am most experienced, also help in the tasks involved with
the release teams? Maybe have a representative from each team be a member
of the main Release Team?

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

+1

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

At least you and Luke have worked on the sponsors queue. My lack of
sponsoring saddens me quite a bit, and it is an area I am hoping to get
more involved with in Lucid+1, as right now I am smashed with tasks. I get
emails for the sponsoring queue daily, and at times I get quite a bit,
which can get overwhelming. By overwhelming I mean, I just either mark all
as read because I am super busy at that point, or just delete them. I am
wondering if we could incorporate some sort of functionality into one of
the IRC bots to spit something out in one of the channels. I thought the
same would be good for REVU as well in the past. This might spark peoples
interest if they see there is something good that can be done at that
point, instead of reading it in their emails later, and possibly forgetting
about it.

[...]
> B) Governance
[...]
>     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.

There used to be a page on the wiki that had a list of leaders, and I am
sure it is still there. I think this is a worthwhile venture to look into.
However the reporting part is where I am somewhat iffy about. I know that
reporting is a good thing, but as a largely volunteer community, I know
quite a few disregard the reporting for one reason or the other. Some think
that since they are volunteering, they do not need to report what they are
doing, and I understand this. I think we can look at the team reports as an
example. Sometimes they get done, sometimes they don't, and sometimes when
they do get done, they might have been better off if they didn't get it
done.

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

Maybe this would be a good time to do the reporting as listed above. The
last thing I remember about MOTU meetings, is they were not attended
heavily, and in a lot of cases, only 1 or 2 people would show up, if any at
all. I think weekly meetings might be a bit tough to achieve, unless a
meeting spark is lit under the rears of many.

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

I don't know about this one honestly. Overseeing MOTU leaders and the MOTU
community is valid I think as well as facilitating meetings, however the
conflict resolution really isn't. During my tenure on the MC, I only
remember one instance of conflict resolution. I think conflict could easily
be handled by the MOTU leaders, and if needed the Community Council.
Actually, I think the MOTU Leaders would be a high enough level, and we
wouldn't need a MC. The MOTU Leaders could possibly report as needed to the
TB on a regular basis, ie. at TB meetings.

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

+1

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

+1. I also think we could merge the MOTU, MOTU Council, and MOTU Mentors
mailing lists in to the MOTU list. As the MC and MM lists are very quiet.

> 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!

You should have started off with this last line first, it pumped me up :)
Well that and Daniel beating me up on IRC :)

Thanks a ton Emmet for taking care of this. Very well crafted of course. If
everyone could voice up, that would be great!

-- 
 Name|  Richard JOHNSON
Title|  Developer
  WWW|  http://www.ubuntu.com
Email|  nixternal at ubuntu.com
GnuPG|  3578 0981 A21D D662 2A96  7623 F4C1 838C D8C4 4738
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/ubuntu-motu/attachments/20100225/a4504f71/attachment.pgp