DeveloperCommunication
Size: 6206
Comment: updated draft
|
Size: 6238
Comment: EditedSpecification, bumping up state
|
Deletions are marked like this. | Additions are marked like this. |
Line 13: | Line 13: |
* Status: DraftSpecification, DistroSpecification, ColinCharlesQueue, SimonSharwoodQueue[[BR]] | * Status: EditedSpecification, DistroSpecification, MatthiasUrlichsQueue, BenjaminMakoHillQueue[[BR]] |
Line 28: | Line 28: |
Communication within the Ubuntu developer community is primarliy 'ad | Communication within the Ubuntu developer community is primarily 'ad |
Line 30: | Line 30: |
to follow for many developers. As a result, evencore developers are sometimes not aware of changes in the release project. This BOF seeks |
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 |
Line 55: | Line 55: |
subject should be used if the traffic is not too high; there alrady | subject should be used if the traffic is not too high; there already |
Line 77: | Line 77: |
on IRC sometimes have not always been inforned; the release state and | on IRC sometimes have not always been informed; the release state and |
Line 112: | Line 112: |
* Sounder is kindof the off-topic mailing list | * Sounder is kind of the off-topic mailing list |
Line 126: | Line 126: |
* UBuntu-status web site (Wiki page?), www.ubuntu.com/devel, like developer.gnome.org | * Ubuntu-status web site (Wiki page?), www.ubuntu.com/devel, like developer.gnome.org |
UbuntuDevel/DeveloperCommunication
Status
Created: Date(2005-04-24T00:14:39Z) by MattZimmermanBR
Priority: MediumPriority BR
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)
UbuntuDownUnder/BOFs/DeveloperCommunication (last edited 2008-08-06 16:33:04 by localhost)