Re: [Debconf-team] Why do we have two lists for debconf-team ?
On 11/07/13 00:46, Raphaël Walther wrote:
On 11/03/13 17:16, Steve Langasek wrote:
On Sun, Nov 03, 2013 at 09:45:58PM +0100, Raphaël Walther wrote:
The original motivation was to have a mailing list where we could begin
discussing DC14 planning while DC13 was still under way. I think this is a
good idea in general.
Now that DC13 is over, the focus on both lists will be DC14, so it may make
sense to have everyone on a single debconf-team list. However, I have no
idea if everyone who's subscribed to debconf14-team has also subscribed to
debconf-team. Furthermore, as we're going through DC14 organization, I'm
Here is my suggestion:
* Mothball 'debconf-team' going forward --- maybe use for DebConfN<14
topics, but no longer for DebConf14.
* Use 'debconf14-team' for all DebConf14 related work.
* When it's time to start discussing DebConfXX in the future,
create the corresponding debconfXX-team list.
* Return to using 'debian-portland-soc' for announcing meetups at
the Lucky Lab and other social activities not related to DebConf14.
W.r.t. the last point, the duplicate emails are annoying. If one wants to
attract DebConf14 participation from people subscribing to debian-portland-soc
in the future (all 1 of them, maybe), then stick an advert in the welcome-
Well, my point of view is one team, one list :) (and keep the 10 years of archive)
I think you may have misunderstood the nature of my suggestion; I will
try to clarify:
* By all means, keep the debconf-team archive around! However, deprecate
future use of that list (e.g., auto-reject inbound traffic, with a
bounce message that directs the sender to one of the new event-based
* For future traffic, begin using lists of the form "debconfNN-team",
e.g., debconf14-team. The goal is not to segregate people, but to
segregate content, to make it easier to for team members to follow
traffic relating to one DebConf versus another. Apparently the
cross-chatter from discussing two different DebConf instances in one
list can be detrimentally distracting, otherwise Steve would not have
created an independent debconf14-team list. I imagined that there is
some likelihood of this happening any given year, if planning for the
next event begins before the current event is completely wrapped up.
This is not so dissimilar from the notion of using a separate email address
"NNN@bugs.debian.org" for each reported bug, versus using a single monolithic
"firstname.lastname@example.org" list for *all* bug report traffic. Indeed, all developers
working on bugs are on the one and same team ("Team Debian!"), but since bug
reports are often managed as mostly independent entities, it is helpful to
split the traffic by reported bug.