UbuntuDevel/DeveloperCommunication

Status

• Created: Date(2005-04-24T00:14:39Z) by MattZimmermanBR

• Priority: MediumPriority BR

• People: MatthiasUrlichsLead, BenjaminMakoHillSecondBR

• Contributors: JaneSilberBR

• Interested: BR

• Status: EditedSpecification, DistroSpecification, MatthiasUrlichsQueue, BenjaminMakoHillQueueBR

• Branch: BR

• Malone Bug: BR

• Packages: BR

• Depends: BR

• UduSessions: 4 BR

Introduction

This spec lays out a plan for solving a number of problems with communication of important release and developer information within the Ubuntu developer community.

Rationale

Communication within the Ubuntu developer community is primarily 'ad hoc', and distributed in a number of different places making difficult to follow for many developers. As a result, even core developers are sometimes not aware of changes in the release project. This spec and accompanying BoFs seek to define and implement structured methods and channels for communication among the Ubuntu development community.

Scope and Use Cases

• Daniel wants to upload a package. However, the next Ubuntu release is not too far away, and he is not sure whether his changes are still appropriate, need to be approved, or have to be deferred.
• Frank and Jane argue about something on the ubuntu-devel mailing list. Their argument gets more and more non-constructive, and some cooling-off seems to be necessary before the problem escalates. However, both are not backing off on their own.
• Mark wants to bring a problem before the Community Council. He needs to know the schedule for the next meeting, and possibly the next two if he can't make the first one.

Implementation Plan

Mailing lists

Most work in Ubuntu happens on mailing lists.

We will continue to create lists for LoCoTeams as soon as a prospective team exists and has an entry on the list in the Wiki.

Developer communication will continue to use the main ubuntu-devel mailing list for most topics; it's reasonably quiet (300 messages/week). For team-specific topics, a [TeamName] tag in the subject should be used if the traffic is not too high; there already are a small number of lists for specialized topics (kernel-*, -hardened, -translators). For now, this scheme works and thus shouldn't be changed unless a problem develops.

Ubuntu-sounder is designated for off-topic traffic.

In terms of behavior on mailing lists and maintaining the CoC, we should be more willing to consider temporarily preventing people from posting to a list ("ban") but should this should be done lightly. Other methods of de-fusing a fast-moving argument should be preferable. For example, all messages which mention a "hot" topic can be held on a wait queue for a few hours.

If that does not help, or of somebody is deliberately or repeatedly violating the CoC, a ban might be necessary. It requires the agreement of more than one Community Council member.

Release Communication

As of today, there is no communication problem for the core team. However, people who are not generally present in #ubuntu-devel on IRC sometimes have not always been informed; the release state and many of the milestones along the way are announced to ubuntu-devel, but not in a regular and organized way beyond that channel.

We will therefore create an ubuntu-maintainers mailing list for appropriate announcements, which every maintainer needs to be subscribed to. In addition, an Ubuntu-status web site or Wiki page? (proposed location: www.ubuntu.com/devel) will be created.

Meetings

The rotating schedule for CC meetings has been good. However, the early-morning(UTC) meeting was a failure, as no CC member was present. We will find two or three times for meetings, with reasonable schedule overlap for everybody. This was handled in the MembershipAndMaintainershipProcess BOF.

UDU BOF Agenda

• Mailing list organization - what traffic should go where?
• Communicating status information for critical release periods (e.g., milestone release prep, freezes)
  • Can I upload now? What types of changes are appropriate?
• Announcing and otherwise managing scheduled meetings

UDU BOF Notes

• Mailing list organization
  • mako is going to be mailing list admin
  • until now, policy has been: create local list for loco teams, no question

  • Teams are encouraged to use -devel; if team-specific you can use [TeamName] in the subject

  • -devel is a reasonably quiet mailing list (300 msg/week)
  • There are a couple of other lists (kernel-*, -hardened, -translators).
  • Unless there's a problem, nothing should change
  • Sounder is kind of the off-topic mailing list

  • Create a new list for LoCo teams

  • CoC on mailing lists
    • Problem topics (like Debian's Vancouver) can be held for a few hours

    • Proposition: Temporarily ban somebody if >1 CC members agree

• Release stuff
  • No communication problem in the core team
  • not so clear for people who don't hang out on #ubuntu-devel
  • is announced to ubuntu-devel, but not organized
  • important messages (preview) are mailed to ubuntu-announce
  • Locking everything doesn't work too well for feature freeze
  • Proposal: Create an ubuntu-maintainers mailing list for appropriate announcements which every maintainer needs to be subscribed to
  • Ubuntu-status web site (Wiki page?), www.ubuntu.com/devel, like developer.gnome.org
  • Manually approve uploads in the later stages of a freeze
• Meetings
  • CC meetings are sometimes announced by email
  • Meeting times were rotated, which ended up badly for early-morning meetings
  • A rotating schedule in itself is fine, though
  • Find two or three times with reasonable schedule overlap

UDU Pre-Work

Comments

• DanielHolbach: Communicating major transitions to MOTU Crew (to make complete transitions)