This meeting was held Tuesday 26 October 2004, at 16:00 UTC, in the #ubuntu-meeting channel on irc.freenode.net.
Summarized by: Benjamin Mako Hill <mako@canonical.com>
Full Log Available: http://people.ubuntulinux.org/~mako/cc-meeting_log-20041026.html
Discussion of proactive security
Mentoring new developers:
Lots of people are interested in developing for Ubuntu, but don't know how. It might be appropriate for us to spend some time on mentoring a few of them as Hoary starts up.
Formation of the Masters of the Universe
Future of the Documentation Team; appointing a team leader:
Many works had already begun, however it seems most of it is disorganized, scattered and looks more like random bits. We need a leader, who'd be the common authority point of collaboration, who'd centralize things, outline his long term documentation plan and make sure decisions are made in accordance with the Ubuntu's Code Of Conduct.
—Sivan Green
Before the meeting, Colin Watson pointed out on the wiki that, "surely this is a matter for the technical board, not the community council?"
John Moser, the person who posted the suggestion on the agenda replied, "maybe. I was thinking more do the users want more security' over 'do the maintainers want to spend time on this.' I'll idle in the IRC channel on Freenode for now; if you'd like to discuss this I'm up for it. Move this to wherever appropriate and get rid of these anecdotal messages."
At the meeting, Colin Watson qualified his earlier comment saying, "actually I'd say the deep discussion should happen on ubuntu-devel; the tech board should take any hard decisions that aren't clear to the development community, I feel."
Mentoring means that developers or maintainers in Ubuntu with more experience will be paired up or otherwise work closely with new maintainers until they know the ropes and can take on a more central, trusted, and unsupervised role within the community. For information on the sort of things that Ubuntu maintainers will be expected to do and the process for becoming a maintainer (in a broad sort of conceptual way) you can check out the maintainer page on the Ubuntu website.
Mark Shuttleworth introduced the discussion saying: "Probably now ubuntu is laking manpower to do mentoring, IMHO We haven't done a good enough job of mapping out a 'new maintainer' process. Maybe that's a good focus for discussion now and will lead us nicely into the 'masters of the universe' topic." He suggested the following breakdown of the issue:
In terms of the maintainer appointments, a few people suggested that they did not want to see the Debian NM process replicated and there was consensus that there should be a fast track for folks that want to maintain package in Ubuntu and who have a long proven record in Debian and perhaps also for those that have a proven technical competence and record for trustworthy decision-making in the Free Software community more generally. At the last meeting, we agreed that both the Technical Board and the Community Council will need to sign off on new maintainers.
Colin Watson pointed out that we don't necessarily need to be as focused on packaging as they might in Debian -- since there are less packages in Ubuntu and since we're pulling heavily from Debian -- and that we can focus on other types of work. It was brought up later that maintainers should not need to know packaging or be trusted for packaging in order to become maintainers if their focus is elsewhere (e.g., writing documentation).
Matt Zimmerman mentioned a BOF on community governance that Jeff Waugh ran at the Warty Ubuntu conference and included the following notes (edited) that describe a brainstormed version of the way that people can get involved broken down at the following levels:
Matt introduced the idea of using a simple command line tool to automate the process of making a patch of an Ubuntu package and putting in a place where an Ubuntu developer will have a chance to look at it plus a dedicated system for tracking these in a queue. The discussion went off on this tangent for a while. Mark Shuttleworth suggested that the system have:
The power of this is that it allows people to point to a web page and show their entire track record. While everyone agreed that this was a good idea, some people it was unnecessary. Benjamin Mako Hill said, "I don't think having a fully trackable full-blown database is necessary for determining if people do work to the point where they would make good maintainers." This could be down in an single email with links to bugs.
The group then moved on to discuss the test of knowledge of packaging policy as it would be important before a person become a maintainer and what the best way would be to execute such a test. A number of members had negative initial reactions to this seeing the similar between this and what some feel are the more problematic parts of the New Maintainer process in Debian. Benjamin Mako Hill said, "I think the best test is just doing something." Colin Watson echoed this point.
Mark Shuttleworth suggested that while past product is essentially, he wanted to know that people could, "give the right answer immediately without reference to the docs." Many attending, including Matt Zimmerman suggested that this was not necessary as this sort of memorization "lets you work faster, but not more effectively."
Because Mark and others still like the idea of some sort of interview in one way or another, the group discussed the virtues of having this either as a telephone interview of online. Colin Watson and other suggested that IRC interview were preferable with language issues being just one point in their favor.
To get a better idea, Mark asked how long he thought the process would take for an average application. The feeling was, for a someone who can code or has technical experience but no experience with Ubuntu, it should take about two months.
Mark Shuttleworth outlined the goals of the Masters of the Universe idea:
Martin Pitt's initial reaction was that a Master of the Universe (MOTU) should always be a Debian developer. A number of people disagreed with him -- but understood what his point was. Martin argued that as we tweak universe, the merging problem and sync problems we've been seeing would be highly aggravated over time.
Matt Zimmerman argued that while we can make it easier for Debian to incorporate out work, we can't do Debian's work for them: "I do not feel that uploading Ubuntu packages to Debian is appropriate, unless the Ubuntu maintainer is also a Debian maintainer and will fulfill the duties of that role."
Everyone agreed that, at the very least, some sort of organized liaison for the work done by the MOTU and Debian should be in place. Colin Watson spoke out most forcefully on this point saying, "it's in our own interests to do this, because otherwise upgrades from Debian will eventually get more and more difficult if there are radically different packagings of stuff in universe sharing the same version number space."
Mark Shuttleworth said, "The universe process is still uncertain, but I think we should leave it as flexible and open as possible. Our default option should always be to look to see if there's a debian package for something."
The last major bit on the discussion was on the idea of tracking and coordinating the MOTU effort. Matt Zimmerman said he was against using Bugzilla for doing this -- or at least the primary Bugzilla -- and that this should be done in a separate Bugzilla.
The documentation team is off to a good start. Mark Shuttleworth and John Hornbeck talked briefly about the status. There was some reminders of the procedure for writing documentation that involved doing work in the wiki and the moving things over to the website once it was ready.
John Hornbeck gave an update on the status of the documentation team, the participants so far, and what needed to be done. There was consensus that having someone designated into a position of keeping momentum going and doing things like wiki gardening would be a useful thing -- something that Mark had discussed with Enrico in the past. They also discussed the idea of having a "core team" instead of a single team leader to help make leadership decisions.
Mark asked:
Enrico and a few others said that a team leader might not be the best idea right now. Everyone agreed that a coordinator was all that was really necessary at the moment.
There was a little bit of less directed talk about whether documents really need to have owners and are best written in what environment of ownership.
Mark ended the discussion with a couple decisions, backed by rough consensus from the group:
In terms of the list of things that need to be written and worked on, Mark suggested that this would need to come from the team itself. He added that he would be willing to help prioritizing and give suggestion but that the work and the decisions would be part of the teams domain.
Mark added that a major measure of the doc teams success will be how well it can bring new people to the table.