Channel setup for Gutsy release

Tue Oct 16 19:46:18 UTC 2007

On di, 2007-10-16 at 21:42 +0200, Lorenzo J. Lucchini wrote:
> 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.

Good

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

Good

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

Which values do you suggest?

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

Good

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

Makes sense, if #compiz-fusion agrees

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

As long as #ubuntu-meta does not become a support channel, that should
be ok.

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

Good ideas, thanks!

-- 
Dennis K.

Time is an illusion, lunchtime doubly so.
-------------- 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/4b06d5a3/attachment.pgp>