UbuntuDevel/DeveloperCommunication

Status

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

• Priority: MediumPriority BR

• People: MatthiasUrlichsLead, BenjaminMakoHillSecondBR

• Contributors: JaneSilberBR

• Interested: BR

• Status: DraftSpecification, DistroSpecification, MatthiasUrlichsQueue, BenjaminMakoHillQueueBR

• Branch: BR

• Malone Bug: BR

• Packages: BR

• Depends: BR

• UduSessions: 4 BR

Introduction

(so, where's the intro and rationale?)

Rationale

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

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 alrady 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.

• CoC on mailing lists

Preventing people from posting to a list ("ban") should not be done lightly. Alternate methods of de-fusing a fast-moving argument can be used. 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 matters

As of today, there is no communication problem in the core team. However, people who are not generally present in #ubuntu-devel on IRC sometimes are unsure; the release state is announced to ubuntu-devel, but not in a regular and organized way.

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 was OK in general. 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.

Data Preservation and Migration

N/A

Packages Affected

N/A

User Interface Requirements

N/A

Outstanding Issues

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 kindof 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)