Channel setup for Gutsy release

[Lorenzo J. Lucchini]

There are some changes that I would like to operate on the asset of the main 
channels to prepare for the Gutsy release, which will certainly, as we know 
from past experience, bring a lot of load especially to #ubuntu.

- IMPLEMENTED: open #ubuntu-release-party for countdown, partying after 
release, and questions strictly related to release time, download servers / 
torrents load, new features enquiries.
* Rationale: people will want to "celebrate" the release, and we should allow 
that, but that shouldn't impair regular support. This has been tested before.

- PROVISIONAL: keep #ubuntu+1 open, and use it for Feisty->Gutsy upgrade 
questions only, while #ubuntu should be used for "installed-system" questions 
only (see !upgrade).
* Rationale: upgrade-related questions will make up a big part, probably the 
majority, of support questions in the week(s) to come. As with past releases, 
certain people will naturally "specialize" in upgrading problems, making a 
dedicated channel appropriate. On the other hand, "normal" support questions 
shouldn't be lost in the scroll-hell and left unanswered.

- TEMPORARY: set +J channel mode on #ubuntu, with appropriate throttling 
values (as tried in the past). Monitor #ubuntu-unregged constantly for 
overflow.
* Rationale: let's face it, we are going to experience many more attacks than 
usual, and given the increased amount of people in #ubuntu and the increased 
amount of messages, repeated attacks would simply make the channel 100% 
useless. While +J still has some problems, and we should handle it carefully, 
it will likely allow us to manage the channel better.

- TEMPORARY: apply a policy of using /remove with a descriptive message, 
accompanied by a relevant bot factoid or by another form of more verbose 
explanation in PM, as a first warning for disrupting behaviors. Set a ban if 
the same person keeps misbehaving afterward.
* Rationale: this is not very different from what we are normally supposed to 
do. But keep in mind that it's important to give a warning kick before 
banning, even in cases that seem "obvious trolls" on the moment, because 
although it may seem to make things longer initially, it helps avoiding long 
arguments in #ubuntu-ops, which distract us from monitoring the "real" 
channels. A kick, compared to a !factoid warning, also has the advantage of 
being listed in the bantracker, making it easier to understand the situation 
later.

- PERMANENT: Keep questions strictly related to the official Desktop Effects, 
as supported on the cards it's officially supported, in #ubuntu, but move 
everything else effects-related to #ubuntu-effects.
- PROPOSED: Close down #ubuntu-effects, and redirect its users to 
#compiz-fusion, after making the appropriate arrangement with that channel's 
operators.
* Rationale: There is no reason to not support Desktop Effects in the main 
channel, since Gutsy makes it a first-class citizen of Ubuntu. However, that 
was achieved by selecting carefully which hardware is well-tested enough to 
enable effects by default, and we should reflect this selection by making it 
clear that if a card is not officially supported by Ubuntu, then we don't 
officially support it either, and that we offer #ubuntu-effects for those who 
want to try it anyway.
Since #ubuntu-effects is slowly but steadily becoming silent, however, and 
since the incorporation of Desktop Effects in Ubuntu means that all 
other "effects" questions are more Compiz related (Beryl is not supposed 
anymore by anyone, basically) than Ubuntu related, phasing out the Ubuntu 
channel in favor of the dedicated Compiz Fusion channel may make sense.

- PERMANENT: Make #ubuntu-meta the official channel for helpers to consult 
among each other on (strictly) other people's question that they cannot 
answer fully, and report on complex questions that remain unanswered.
* Rationale: I know you saw this coming... #ubuntu is always busy, and it 
becomes very, very busy at release time, when many voices start stating that 
the channel should be split into several topic, or other schemes that, while 
possibly valid, would undoubtedly disrupt the channel for a while, and can be 
hard to step back from. A "buffer" for support question is an "opt-in" 
addition that cannot in any way affect the smooth operation of #ubuntu and 
other support channels.



Since there is little time left before release, I will consider the above 
changes as active.
However, if you strongly feel that any of them should NOT be implemented, 
please state so clearly on this list, and they will be considered as put on 
hold.
Feel also free to discuss them and voice your opinions even without the 
intention of definitely and immediately reverting them... but don't forget 
that, during these days, the most important thing is to have *some* setup 
that allows to keep the channels manageable, rather than discussing things 
that will be implemented, if ever, at much later stages.



by LjL
ljl at ubuntu.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.ubuntu.com/archives/ubuntu-irc/attachments/20071016/fff72fa4/attachment.pgp>