On 2010-02-22 12:53:09 +0900, Emmet Hikory wrote: > 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.
The MOTU School page already contains "*** MOTU School has been retired in favor of Packaging/Training*** - These pages remain just for historical record" (added in May 2009). > 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). I see MOTU more in the function of keeping universe (later the unseeded packags) functioning (as far as possible). So the MOTU work is more QA style and continues to be it. And I don't see how adding new package benefits this target in the long run as most packages on REVU seem to be done by drive-by packagers who vanish again once their package is in the archive. Such a package might benefit Ubuntu in the short term but without a maintainer (being it a person or team in either Debian and/or Ubuntu) may harming Ubuntu in the long term. It doesn't serve the Ubuntu users when we ship old packages and upstream won't be happy either with getting support request from users using this old packages. 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. > 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. The problem I personally have is that I don't know how to usefully help with security updates. Grabing a security patch from Debian is mostly easy (depending how far the Debian and Ubuntu package differ), applying it to our packages and testing if it still builds is easy but then the hard part comes: how to test that the package really fixes the security problem? For SRUs there is a step-by-step guide how to reproduce a problem. But for security problems? Often I can only find a description of the problem and patches but not a ready test case against which I can check that I didn't break it again while backporting a fix (e.g. by missing an important patch). [But I've to say that I didn't try to do security updates in the recent past]. > 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. Perhaps this should be coordinated with the other teams and we should a common understanding how mentoring should work to not confuse new developers who look/try different teams with different style of mentoring (as far as possible). > 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). +1 > 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. IMHO we should take our time with this and not hurry unnecessarily (but not to prolong it indefinitely either). First MOTU should get accommodate to the new world order with its package sets and figure out where we stand and in which direction we are heading. Unlike most other current teams MOTU has a history and its own processes while the other teams can start nearly from fresh. Therefore we need to figure out what parts from the past survive the reorganisation and what kind of leadership/goverance we will need for it. For me it still not fully clear how the future MOTU will look like in the end. > 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. 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. > 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. > 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. > 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 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) Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
