Technical Board Assessment - Jaunty Cycle

Written by Jono Bacon jono AT ubuntu DOT com, April 2009

Purpose

This document outlines some recent research that I have conducted into the Ubuntu Technical Board (TB) in the interests of assessing its efficiency in the Ubuntu community. This research was conducted in interviews with the current TB members, interviews with approved developers who have become core developers and additional input from other parts of the community. All of this input has been anonymised and merged into the document to ensure the research can be as honest and frank as possible.

It should be noted that this document should be interpreted as guidance. It should not be interpreted as a directed and stated set of changes that must occur.

Current Documented Purpose Of The TB

The primary documented codification of the TB is available at http://www.ubuntu.com/community/processes/techboard. This page outlines the primary mission statement of the TB as:

"The Ubuntu Technical Board is responsible for the technical direction that Ubuntu takes. The Technical Board makes final decisions over package selection, packaging policy, installation system and process, toolchain, kernel, X server, library versions and dependencies, and any other matter which requires technical supervision in Ubuntu".

In addition to this the page clearly stipulates three primary areas of responsibility:

• Ubuntu Packaging Policy
• Ubuntu Release Feature Goals
• Ubuntu Package Selection

With the above, the TB is not directly involved in feature goals and package selection in a formalised capacity, although arguably drives decision-making around packaging policy. While the individual participants who are members of the TB are involved in the above work, they are performing this work on their own behalf as opposed to that of the TB. The first incarnation of the TB initiated the creation of the processes that handle the above, but the TB does not do this today as a formalised entity. Much of the above responsibilities are primarily handled by Canonical and Canonical developers.

Aside from the above agreed mandate, the page does not include a set of responsibilities that have been taken on by the TB:

• Core Developer Approval
• Developer process approval
• Restricted (ACL) Developer Approval
• Alleged Patent Violation Investigations
• Escalation Point for Developer Issues and Concerns

These responsibilities should be delegated, documented and made part of the TB mandate.

In addition to these formalised roles, the TB has taken on very much an advisory role. Developers were of the opinion that the TB is a suitable place to take technical uncertainties and questions and it appears this role is clearly felt within our developer base. It could be valuable to emphasise and optimise this function in the TB.

Additional Proposed Focus

While the respondents were in favour of the above set of general operational activities, it was also felt that some specific areas needed more focus and leadership from the TB:

• ArchiveReorg

• PulseAudio and on-going sound quality issues

• Kubuntu
• Mono
• DX work and its integration in Ubuntu
• UDS session approval
• Changes to seeds

It could be useful for the TB to discuss these topics and offer an opinion in the interests of leadership, direction and a solid technical grounding.

In the interests of optimising technical advice and supervision, it could be useful to develop a method which the developer community can vote on the topics on their mind for the discussion at some TB meetings. There is a general feeling that the TB could provide a beneficial technical input on common themes across the community.

RECOMMENDATIONS

• For http://www.ubuntu.com/community/processes/techboard:

  • The responsibilities list should be updated and expanded with additional responsibilities.

  • The membership is out of date and should instead link to https://edge.launchpad.net/~techboard.

• The TB vote to determine if they should offer input on Pulseaudio, Kubuntu, Mono and the DX work.
• It could be useful for the TB to have a regular session (possibly bi-monthly) in which the TB has a Call For Topics in the core-dev/MOTU developer community and the most common topics are discussed at the meeting and advice and insight is offered from the TB. This would help provide a function in the community in which the TB is pro-active as opposed to being reactive with topics of question or concern on an agenda.

Execution

Meetings

All respondents agreed that fortnightly meetings are sufficient, and the majority of meetings can cater to all agenda items published at https://wiki.ubuntu.com/TechnicalBoardAgenda without overrunning.

There was a concern raised that meetings have had to be deferred due to not being able to maintain a quorum. This is a complex problem to fix and throwing more bodies at the TB is not necessarily going to solve it. In these cases it is recommended to take topics to the TB mailing list.

While this is not affecting real-time TB meeting on a regular basis, one possible solution could be to ensure that a minimum level of attendance is expected in members and if this cannot be maintained, the member should gracefully step down. It is recommended that this approach only be applied if there is significant concern around the maintaining quorum.

Reporting

There majority of opinion felt that minutes and notes from TB meetings are effectively redistributed to the wider Ubuntu community via the ubuntu-devel and ubuntu-news-team mailing lists. The minutes have also appeared in the Ubuntu Weekly News. Some respondents also commented that the reporting of minutes has improved.

Decision Making

The respondents were generally happy with decision making abilities of the TB. Prominent successes were cited as:

• effectively managing developer applications
• determining how individual upload rights would be administered to a particular developer for a single package without going through the MOTU process.
• the cdrecord licensing issue.
• emacs-snapshot discussion with Romain Francois

The only cited concern around the longevity surrounding the patent issue with ffmpeg.

RECOMMENDATIONS

• Keep a close eye on whether quorum can be maintained in meetings. If it becomes a problem, consider a discussion of solutions.

Technical Board Membership

Current Membership

There was a general feeling that membership should be expanded if it brings a practical benefit to the board. This expansion was suggested only if the current board is struggling to meet to fulfil its responsibilities. The board feels that the majority of the current members are generally providing enough time for TB activities.

There was a wide agreement that if the TB were to expand further, non-Canonical membership would be valuable, but there is difficulty in finding suitable candidates. We typically seem to hire great candidates.

Appointment

Currently candidates are nominated to the board at Mark's discretion. Although Mark factors in input and evidence into his decision, there was a general feeling that this process should be more explicit and documented. A frequently made recommendation was that approved developers should be able to nominate candidates for the TB. Although the seniority of the board and technical excellence required are compelling reasons to have a more restrictive method of picking candidates, a documented expectation around a vote from approved developers would be a more open and transparent approach.

RECOMMENDATIONS

• Expansion of the board is recommended. We should review https://edge.launchpad.net/~ubuntu-core-dev/+members to determine what candidates are available.

• Annual re-assessment of potential candidacy for the board.

Advisory Positions

Currently the TB is entirely consisted of its primary members and there is no advisory position in place. A topic of previous discussions has been the premise of having advisory roles in place to formalise the relationship between the Ubuntu project and another project such as Debian. The predominance of opinion in the respondents was that advisory positions would not be useful in the TB. The reasoning for this is that (a) the board would unlikely be consulted due to the TB not consulting on general technology issues (it focuses on specific topics in most part) and (b) that the TB should remain focused on representing the interests of the Ubuntu project.

There was however an acknowledgement that the Debian relationship in particular could benefit from a formalised relationship in the project with one such suggestion to have a Debian representative on the board itself. There was consensus that a Debian role in Ubuntu should be visible, participating at DebConf, engaged in discussion on Debian mailing lists and regularly engaged with the project.

RECOMMENDATIONS

• No recommendations on an advisory board.
• TB to discuss whether there should be a place for a Debian representative on the board. While it could be argued that Colin Watson is a natural candidate here, it could be beneficial to have more Debian focused representative in that seat.

Comparative Data

OpenSuSE Board

openSUSE has a board, which shares a resemblance to our Community Council. The board is setup not as a government of openSUSE but more a an ultimate escalation point and as a mediator.

The board does not make technical decisions about the project or guiding the openSUSE project in a specific technical direction unless asked for during mediation. There seems to be no formal governance for this kind of decision making "that's other people's job, e.g. AJ as the director of openSUSE and platform, Coolo as the openSUSE distribution project manager, or Michl as the openSUSE product manager". (http://dev-loki.blogspot.com/2008/09/about-opensuse-board-and-elections.html)

Interestingly the extended goals are detailed as "to support people, projects, initiatives in their bootstrap phase, which means putting the right people in touch, help driving discussions, mediate between opposing parties". In this capacity, the board has a mentoring capacity.

Outstanding Issues

This is the list of outstanding issues raised in this document that need to be assessed by the TB:

• Regarding http://www.ubuntu.com/community/processes/techboard:

  • Update and expand the documented list of TB responsibilities

  • The membership is out of date and should instead link to https://edge.launchpad.net/~techboard

• Regarding input on key issues such as Pulseaudio, Mono and DX work:
  • The TB should determine if they should offer this kid of input and how.
  • Should the TB have a regular Call For Topics in the core-dev/MOTU developer community to discuss areas of interest/concern and advise and provide insight? This would help provide a function in the community in which the TB is pro-active as opposed to being reactive with topics of question or concern on an agenda.
• The TB should provide a means of recording whether quorum can be maintained in meetings. If it becomes a problem, consider a discussion of solutions.
• Regarding expansion of the board

  • Expansion of the board is recommended. We should review https://edge.launchpad.net/~ubuntu-core-dev/+members to determine what candidates are available.

  • Annual re-assessment of potential candidacy for the board. The TB should decide a time for when to perform this assessment.
• TB to discuss whether there should be a place for a Debian representative on the board. While it could be argued that Colin Watson is a natural candidate here, it could be beneficial to have more Debian focused representative in that seat.