Future of MOTU

[Emmet Hikory]

Michael Bienia wrote:
> On 2010-02-22 12:53:09 +0900, Emmet Hikory wrote:
>> 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.
>
> Although REVU is a nice tool, I'm not sure that is fits well in the MOTU
> workflow. It might work better for other teams where the packager and
> the team is really interested in getting the package into the archive
> and (more important) continue to maintain the package (ideally it ends
> in the package set for that team).
<...>
> As long as we don't have good processes to identify this stale packages
> and remove them later again, I don't think MOTU should use REVU much.

    I fully agree with this.  Unfortunately, we have a current
limitation in the way the archive works that limits new uploads to
either MOTU or core-dev.  Until we (being all Ubuntu Developers) find
a good workflow for this and get it implemented in Soyuz, I fear that
REVU will remain at least partially a responsibility of MOTU.  By
coordinating with other development teams, we're in much better
potision to step back from the more questionable packages, yet still
offer advice and support in getting the REVU responsibilitiy
transitioned.

>> 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.
>
> While I recognise the contributions of the MOTU Leaders, I currently
> don't see a need for them. When looking at the MOTU Leaders page and
> striking those out that are either already merged, being in the state of
> merging or being dissolved, there is not much left. And from those left
> I don't see anything MOTU special but only areas where a coordinated
> effort with the other teams would be useful (REVU coordination, security
> updates, mentoring, liasons). And when I think about the past, I don't
> remember much visible activity from those leaders (in their role as
> leaders and not as the individuals occupying those positions).
>
> We should keep our governance/leadership structure simple and flat
> and don't introduce a broad structure (unless really necessary) and make
> it more bureaucratic as really necessary. In the current state of MOTU I
> don't see a need for such a structure.

    My main rationale for retaining it was in hopes that new folk
would step forward to lead various aspects of what we do and help
shape best practices and clear documentation in those areas.  I
suppose this could be left to the several MOTU, but I think having the
means to honor those who step forward helps provide tangible
representation of our only currency: respect.

>> 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.
>
> While I'd would like to see regular MOTU meetings happen again, I also
> see that it's will be a hard task (sorry for sounding pessimistic).
> Without much to discuss I assume only a few people will attending a
> meeting (and stay up late or wake up early) just to hear status reports
> and prefer to read those status reports in the minutes.

    Are there any other strategies that you could suggest that would
help to improve communication and accountability within the team?  My
experience with other teams is that when meetings aren't being held,
growth and activity slow.

>> 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'd wait with forming a MC until MOTU has reformed itself. We shouldn't
> create a new MC just now because we had one in the past.

    I'm fully in agreement with not forming an MC until MOTU is
completely reformed.  I think it's a useful role that needs to be
filled, but attempting to define it prior to sorting MOTU is asking
for it to be given the wrong mandate and be populated by a potentially
non-ideal set of developers (some of whom may not even wish to serve
on swome MC that makes sense for a completely reformed MOTU).

>>     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 witness that too. But I don't know if it's because there is less
> topics to discuss or because the activity from MOTU members moved
> towards other things.
>
> Have we a rough number of how many "active" MOTUs we currently have?
> (with a loose definition of "active" as at least one upload/merge/sync
> for lucid)

    We can certainly parse -changes to see who uploaded and who
didn't.  We can even cross-check this to see where uploads happened to
unseeded packages.  I'm not at all convinced this measures activity as
MOTU rather than just uploads.  I know that most of what I personally
do doesn't result in me uploading something (but rather someone else
uploading something, sometimes to Debian).  I suspect similar is true
for others active in new developer training or developer support.  I
also think this poorty serves those who spend lots of time on the hard
stuff, and unfairly encourages those who have 1000 trivial uploads
(e.g. I don't want to wait for it to reach Debian testing).  We can
measure mailing list and IRC traffic, but that's also not necessarily
a good indicator.

    I think we'd have to deinfe "active MOTU" in some objective way
prior to being able to get a count.  That said, we *can* discover
which MOTU have no mailing list posts, no IRC traffic, no uploads, no
REVU comments, etc. during a given cycle.  Depending on whether we
account for package sets, this list will either be skewed to imply
many active MOTU who have done nothing in target packages or
artifically suggest that most developers are inactive in MOTU (even if
they are active in other areas).

-- 
Emmet HIKORY