DeveloperCommunication

Differences between revisions 1 and 18 (spanning 17 versions)
Revision 1 as of 2005-04-10 23:52:59
Size: 298
Editor: ca-studio-bsr1o-251
Comment:
Revision 18 as of 2005-04-29 06:53:03
Size: 5751
Editor: intern146
Comment: Guys, can you review intro and rationale. editors will review once they are done
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
= People = ## page was renamed from UbuntuDevel/DeveloperCommunication
## page was renamed from UbuntuDownUnder/BOFs/UbuntuDevelopment/DeveloperCommunication
Line 3: Line 4:
= Goal = = UbuntuDevel/DeveloperCommunication =
Line 5: Line 6:
= Requirements = == Status ==
Line 7: Line 8:
= Agenda =   * Created: [[Date(2005-04-24T00:14:39Z)]] by MattZimmerman[[BR]]
  * Priority: MediumPriority [[BR]]
  * People: MatthiasUrlichsLead, BenjaminMakoHillSecond[[BR]]
  * Contributors: JaneSilber[[BR]]
  * Interested: [[BR]]
  * Status: DraftSpecification, DistroSpecification, MatthiasUrlichsQueue, BenjaminMakoHillQueue[[BR]]
  * Branch: [[BR]]
  * Malone Bug: [[BR]]
  * Packages: [[BR]]
  * Depends: [[BR]]
  * UduSessions: 4 [[BR]]

== Introduction ==

This spec describes the ways the Ubuntu community can communicate among itself, horizontally and vertically.

== Rationale ==

At present, communications are ''ad hoc'' and hard to track.
If we can define and implement more structured methods for communication, we can all be more productive.

== 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 ===
Line 10: Line 82:
 * Cataloguing and communicating decisions and rationale
 * Real-time status information for critical release periods (e.g., milestone release prep, freezes)
 * 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
Line 13: Line 86:
= Pre-Work = === 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)

UbuntuDevel/DeveloperCommunication

Status

Introduction

This spec describes the ways the Ubuntu community can communicate among itself, horizontally and vertically.

Rationale

At present, communications are ad hoc and hard to track. If we can define and implement more structured methods for communication, we can all be more productive.

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)

UbuntuDownUnder/BOFs/DeveloperCommunication (last edited 2008-08-06 16:33:04 by localhost)