#ubuntu too noisy to be useful

This is a known issue.

The limitation that the IRC Team has come across in trying to rectify this is how to efficiently split the 1400 users in a way that does not further reduce the quality of assistance.

If we choose to require a foyer, then that uses up personhours that would otherwise be dedicated to technical help instead. A subsequent issue that arises from this technique is that users feel palmed-off and more like a number than a person. Think of any phyisical-world queue, for example.

Another potential fix is to encourage more support in local team channels, however this is limited by the help available in these channels.

Any further ideas are most welcome.

ubottu should ask several questions of every new person in the channel:

what version of ubuntu?
what architecture?
what general area does the problem pertain to?

say, 9.04, x64, flash.
then they get redirected to #ubuntu-64-flash
or some such thing.

...although in Nebraska I'm trying to pull support into our LoCo channel.
That brainstorm comment form also has some good ideas I think.

I remember #python had this problem for a bit. The solution was to load-balance users off to ##python as appropriate, so some users would end up there when joining #python. It works pretty well from a user experience in that you don't have to think or know about it. There is probably a general cap of users where a channel stops being useful; deciding this and splitting into a 2-3 channels might be helpful. Perhaps we should have #ubuntu[1-X] and joining #ubuntu load-balances you into one. However you can always manually join the explicit numbered channel if you for some reason need to.

It seems to me that some inherently useful criterion should be used for load distribution before random numbers come into play.. I think a lot of non-english speakers come into #ubuntu just to get asked to go to #ubuntu-es, #ubuntu-fr, #ubuntu-ru, or whatever.. couldn't that be done automatically based on their IP address?

..then how about an #ubuntu-en-central, #ubuntu-en-pacific, #ubuntu-en-mountain, etc, for time zones?

One large problem that arises when splitting up the help channels is it means the people who help have to watch multiple channels, for instance:
Helper knows about GRUB issues and flash issues, sits in #ubuntu-flash and #ubuntu-grub. He then has to switch back and forth between the channels in order to help people with both issues. The switching means he now spends more of his time reading the backlog (which he missed when he was viewing the other channel) and his total productive time goes down.
Sure, when you're dealing with two channels, this may not be an issue, but four? six?

If person-B has a problem with sound (and happens to know GRUB), B joins #ubuntu-sound, and probably would not join #ubuntu-grub (because B is looking for sound support). If person C comes around and asks for grub help, person B wouldn't ever know, and wouldn't be able to help C (in a monolithic #ubuntu, this scenario happens often). In six weeks, person B comes back with a flash issue, and likely wouldn't re-join #ubuntu-sound (where person D just happens to have the same problem B originally had).

Splitting the channel up like this really puts a damper on much of the give/take atmosphere of community support. If we had some sort of staff doing dedicated support, then this sort of splitting might make sense, but since it's not, this seems like it's just going to end in frustration from both sides.

The logistical aspects of the split are also interesting. If we split by timezone, does that mean that supportees need to find a supporter who both is knowledgeable about their specific issue as well as in their general time-area? Splitting by topic requires a good deal of triage as sometimes initial problems turn out to merely be symptoms of other problems. Bouncing people around from -flash to -sound means an increase in overhead (someone has to brief -sound on the situation, which causes scrolling that otherwise wouldn't have occurred).

What if we replaced irc socialism with capitalism somehow? ..some kind of karma system for problem reports on irc, so people are always on the lookout for other people they can help to build their karma to bounty their own trouble tickets?

Damn launchpad ate my last comment!

I don't think IRC is the right technology for organising volunteer community support, just like blogs are not the right place to report community bugs, irc may not be the right place to deal with support requests.

Personally I've been looking into an XMPP based solution that would enable both multi-chat and one on one support, then you can organise timezones, languages, what ever takes your fancy. In the project I also want to make it easy to log problems and graph what kind of support questions keep on cropping up.

But I could do with much more input and peer review, since these ideas and designs are not yet tested in the field.

I'm a member of the Ubuntu IRC Council.

@Marten Owens - IRC isn't going anywhere if people like using it. Lets not force people away.

It would be great if you could bring concerns & ideas to the Ubuntu IRC Council, the team that manages Ubuntu's IRC presence on freenode.

We have a meeting this Friday at 21:00utc in #ubuntu-meeting, or you can email us at <email address hidden>

Instead of asking the same questions to every person who comes into a channel, what about an extension for the default ubuntu irc client that has all that information available through it? Like a useragent for irc, someone comes into a channel, you do a whois or whatever, and you can immediately tell they're on 64 bit ubuntu 9.10 or whatever, and a bot can send them to the right channel..

I have added this to the IRC Council agenda (https://wiki.ubuntu.com/IrcTeam/IrcCouncil/MeetingAgenda) for Friday's meeting, although I probably won't be able to attend due to travel.

I think that there are a couple of ways that we can deal with this issue. Perhaps an "idle" bot can be present and when someone hasn't made any comments within 24 hours it temporarily boots the offending Nick (no offense nali :-)). This would cut down the amount of people in the channel overall but still allows rejoins. I too am guilty at times of lurking there myself. Usually it's only in case someone is in need of help and I have a little extra time on my hands and I forget to leave the channel when I am finished. With the size of the channel, and so many people it is difficult to utilize that channel to provide solid help to those in need.

Perhaps a bot can be coded up that listens for keywords and notifies a group of willing individuals that someone actually does need help based on those keywords?? When the individual or group is notified if anyone has the time they could simply join the channel and provide assistance. This is just a basic idea that I would welcome any input to refine!

Thanks for your time!

Chris Crisafulli
itnet7

I fail to see how booting out the lurkers who by their very nature are not contributing (at that time) to the discussion will make #ubuntu any easier to follow. Surely it's the volume of people talking, and the number of separate topics under discussion at any one time which is the issue here, not the number of people sat in the channel?

Alan, correct. Chris, your keyword idea is great.

Any time someone in #ubuntu says colemak, gnome-globalmenu, or xmonad, let me know.

There's no need for a bot. Simply have individuals set "hilight" words in their client for whatever they are familiar with.. You ethana2 could for example set a highlight on "colemak" and whenever someone says it your irc client will notify you. This of course depends on having a decent irc client, and individuals managing their own hilight lists - which seems the best course of action anyway. If "colemak" comes up you can choose whether to react and help or if you're busy, to ignore it.

I use pidgin..

Popey,

I hear what you are saying about the hilight words and have used it in the past myself, I just thought it might be a good idea to have a notification Bot that could report to say an IRC support Group in Launchpad for #ubuntu, that would also give some new contributors a place to begin contributing as well.

I still feel that there is an issue though with the amount of people that are lurking in #ubuntu. People are coming into other channels because they say that there is an overwhelming number of people in #ubuntu and they feel that they will not get the attention they need or they feel intimidated. Most users are pointed to #ubuntu from the get support links on Ubuntu's main page. I can tell you from my own experience with irc, I was nervous at first of joining any irc channel and felt intimidated with only a handful of people I can only imagine what it would be like with 1400.

Thanks for your time,

Chris C.

I don't think most people are intimidated by the number of people who are in #ubuntu. They are intimidated by the number of people talking in the channel. The large number of active participants makes it difficult to keep up with a conversation and to get questions asked/answered. Lurkers do not contribute to this problem, and I see no reason to kick them out. As for the bot idea, have you tried using MetaBot? If not, there is a wiki page that explains how to use it: https://wiki.ubuntu.com/MetaChannel

Yes, I originally created #ubuntu-meta (and MetaBot, although that was supposed to be just a part of it) precisely to try and address these issues.

The advantage of it over other approaches is that it doesn't attempt to change #ubuntu in any way, but merely supplement it transparently and make it more manageable for helpers. On the contrary, other proposals I have come across would involve making drastic changes that would be hard to transparently undo if that proved necessary.

I have to say, regrettably, that the people who were most vocal about #ubuntu being "too crowded" were often also the ones who, while seeming interested about #ubuntu-meta initially, didn't really contribute to it in any meaningful way - and an appropriate people contributing to a channel is the only way to ever make it work properly... which goes both for #ubuntu-meta and #ubuntu itself.

Lorenzo: do you think it'd make sense to write up all the tasks that'd need to happen to make #ubuntu-meta a reality and ask for participants afterwards? Kind of like a mini-spec?

Wait, what? #ubuntu-meta *is* a reality, it has been for a while, and I have invested some time in making the bot for it, as well as a limited amount of time writing documentation about it.

I do believe the one thing it IS missing is partecipants. That takes one thing: people willing to join it and contribute.

I might not have advertised that channel very aggressively, but 1) I don't believe in aggressive advertisement of channels, 2) my then fellow operators, including the IRC Council, didn't seem particularly enthusiastic about the channel at the time, more like "make if you really feel it should exist" - so I wouldn't push it overly.

But now seriously, I just hope people would *give it a decent chance* before assuming the only solution to #ubuntu's problems is changing the way #ubuntu works completely.

Nathan: Thanks for letting me know about MetaChannel

Lorenzo: I really appreciate the efforts that you made with #ubuntu-meta. If I would have known it existed I would never have suggested using something else. With that being said, I will try to and contribute. I only repeated the feedback that new users were giving me when coming into our loco channel looking for help from Places like, Puerto Rico, Tunisia, China, and a couple other places I'm sure. I am going to try and learn more about #ubuntu-meta, and see how I can help.

Chris C.

Sorry Lorenzo: I misunderstood things - great work on it!

What are prominent pages where we advertise #ubuntu at the moment? help.ubuntu.com? wiki.ubuntu.com? With the new freenode chat, we could even simply add things like this to the wikis:

[[http://webchat.freenode.net/?randomnick=1&channels=ubuntu-meta | Find the right place on IRC]]

... or something.

Well, I'd say "the" prominent page where #ubuntu is mentioned is http://www.ubuntu.com/support - though personally I believe the best way to advertize #ubuntu effectively would be to have a client installed by default and connecting to it by default in Ubuntu.

I believe some flavors of Ubuntu do that, but right now I'm not sure that would be SUCH a good thing, since apparently the problem is there are TOO many users... And this does run the risk of people consistently mistaking #ubuntu for a social channel.

Chris, I do certainly realize people in LoCo channels will find #ubuntu pretty intimidating, but keep in mind that one of the main "counter-measures" that has been always used against #ubuntu overcrowding, and which has perhaps not been mentioned here yet, is... LoCo channels themselves!
They help a lot having smaller channels to direct traffic to based on language, and I do believe having high quality LoCo channels in general helps keeping the pace reasonable in #ubuntu.

I have attempted to pull ALL Nebraska support into #ubuntu-nebraska, and
will continue to do so unless another solution presents itself.
I also refer people for support to
www.ubuntunebraska.info
which uses that channel also.

+1 to what Neal wrote on commentary #5 keeping up with more than a handful of channels is difficult (at least for me). so splitting the channel in subtopics is a Bad Idea (tm)

@ethana2

I'll second that your comment #24, and add some "spice".

LoCo's (the more local the better) are still the best way to get support to everyone. If every community (town, city) had a LoCo, there would be less need to use an IRC channel or channels or other queuing mechanisms for support. I will give you an example: tiny "Ubuntu Kootenay" provides support to two small towns (villages really). There are a few very committed folks in this remote part of BC that get out and spread Ubuntu goodness the old-fashioned way: feet on the street.

It's great that the community is trying to reduce the noise level on #ubuntu, but would that effort be better placed in promoting more localized support?

Most of my ubuntu support is done hands-on and in person, and I do not
expect that to change soon.

I don't see a problem with the ammount of users in the channel.

out of 1400 users in the channel, only a small percentage are active at a single time.
The majority of people I see and observe in the channel get help quickly and professionally, there are always going to be people who don't deem it fast enough support, or struggle to follow the channel when it is moving fast, but that's just takes someone in the channel to pull them to one side, maybe in a private message and maybe help them with the problem, or give them some tips (as popey suggested earlier) on how to follow and filter a busy channel.

The majority of people are well catered for, the minority that struggle the community should hold the hand of them a little more in terms of support for their problem, and support torwards IRC in general.

The remaining few are people who will never get on with IRC - no matter how many people are in the channels, or they are people there to cause an issue, nothing more, these two groups cannot be catered for, but suggestions of alternative support, wiki/forum for example may help them.

There is a ton of ubuntu resources out there, irc is not for everyone, but the majority that use it, do get very effective support from a highly active irc community.

Would it be useful to ask Local Teams to make a more concerted effort to try to harvest their local users to the loco channels? Also, we do autojoin #ubuntu when someone first fires up xchat, maybe we need to revisit that?

Perhaps in the future we can take advantage of Empathy's libchamplain support to find out a general location of a user and automagically send them to the right IRC channel. :)

After talking to Daf he tells me that Empathy's geoclue support might be useful for this. I'm going to pursue this as an idea. Linking to the upstream bug.

Firstly, I don't think that offloading support to loco channels is going to help much. Not all loco channels have the resources to support such requests. Additionally, people don't want to wait for support, so we'll probably get a lot of cross-posting across channels, which can create just as much traffic as in the original problem.

Perhaps Empathy should hide joins and parts in large IRC channels by default in order to make the chat feel like it is moving slower. I personally use a separate irssi window for tracking JOIN/PARTs in #ubuntu due to the traffic they contribute.

Extraneous joins and parts should be hidden by default in ubuntu's default
irc client.

I believe we had an IRC Council meeting last month but nobody from this bug was in attendance so we didn't discuss it.

Please could you get in touch with us. I believe our next meeting is Sunday 7am utc.

Time confuses me so very badly. Not only do we have 12x2 hours in a day,
everybody runs off their own time zone, so..
I hear UTC isn't even London's time anymore. Seriously, Central time here,
when is that?

http://timeanddate.com/worldclock/fixedtime.html?day=9&month=8&year=2009&hour=7&min=0&sec=0&p1=0

The operator team is always available in #ubuntu-ops.

2 AM the night before church. Got it :P

How about instead of permanently breaking #ubuntu into topic-specific channels, we create short-lived temporary channels to help one person with their issue. I liken #ubuntu to a crowded room at a party. If you want to hold a conversation with someone, you each move to a corner of the room so that your conversation doesn't compete with the other conversations and general pleasantries.

If someone needs help that is going to take more than a quick answer, you can ask a bot (ubottu or another) to create a "corner" channel for you. It would create and manage the channel, invite the person you are helping, and maybe announce the creation of the corner and topic to anyone else who might want to follow you there. The bot could then close the room when you're done, and maybe provide a summary of the conversation back to #ubuntu. Additional bot features could be creating a new bug in Launchpad, attaching the corner channel's log automatically.

In response to https://bugs.launchpad.net/ubuntu-community/+bug/392799/comments/37

Quite a few of us already do this, on our own initiative.

When #ubuntu-classroom was started, this was one of it's intended uses. It works well for "one on one" help, if no scheduled classes are going on at the time (scheduled classes may affect up to 1% of #ubuntu-classroom availability). Nobody needs inviting, as it's got quite a few folks in it already.

"provide a summary of the conversation back to #ubuntu" <--- isn't the point of this bug to discuss the reduction of the clutter in #ubuntu?

As an aside, the more functions you mechanize, the number of abuse vectors opens up (which brings us back to the potential of "more clutter in #ubuntu")

Marek,
    Maybe then we just institutionalize the idea of creating a new temporary channel for long-running help sessions. The biggest reason I wanted to use ubottu was to prevent channel-clutter if people forget to leave a channel when they're done with it. I also liked the idea of being able to create a new bug with the attached channel log.

   The reason for the "provide a summary back to #ubuntu" was for situations where the user's problem was not solved, and the people helping them can't do anymore, instead of just dropping the user back into #ubuntu and having to start telling people his problem from scratch, anything they discovered or ruled out in the "corner" could be provided.

   If the process of taking conversations into temporary channels works, and we don't necessarily want to have a bot managing it, can we add something like a !corner command to ubottu that suggests that people take a particular conversation into a new channel and why?

I feel this is another proposal that creates a cure potentially worse than the disease.
People are already confused enough with IRC without having a bot telling them to join another one-off channel. I fear #ubuntu will become a place to discuss how to join other channels and why.

Besides, if we use a different channel for each conversation, how will that be different from a private query? Sure, other people *can in theory* join, if it's a channel, but that's unlikely to happen if a new channel is "spawned" for each help request - at least, #ubuntu-classroom is *one* channel. Are we prepared to make #ubuntu *officially* hand off support to individuals (who may, maliciously or not, give terrible advice) without so much as a chance for someone to see what's going on?

I think when someone posts his/her problem , someone should private messaging him/her in order to leave the space to other, the only problem of this solution , is that problems are more than solvers .

That's far from the only problem with that solution.

People aren't born with in-depth knowledge about Ubuntu, and #ubuntu is, almost as importantly as it is a place to find support, somewhere people can increase their knowledge about Ubuntu and become effective helpers themselves.

Forcing all support issues to be dealt in private messages would completely destroy #ubuntu's ability to create new know-how.

I would never have stayed in #ubuntu if that had been the way it worked.

#ubuntu
1) To active for new users
2) Not to active for those providing support
3) Separating the channels will divide those providing support
4) The default hide joins/parts sounds like a useful idea
5) 1,475 users isn't that many
6) 165 are marked as away but I don't feel that does justice for the actual count
7) #ubuntu-meta looks like an excellent idea.
__ I joined the channel. After seeing this work one time, I like it.

Example of #4:
Before:
13:37 -!- kaeser_ [n=Kaeser@189.26.49.41.dynamic.adsl.gvt.net.br] has quit [Client Quit]
13:37 -!- zilla1 [<email address hidden>] has joined #ubuntu
13:37 -!- kaeser_ [n=Kaeser@189.26.49.41.dynamic.adsl.gvt.net.br] has joined #ubuntu
13:37 < sebsebseb> ctmjr: oh ok, well yes it will flood with peoples name when they leave or re join, but it could be useful to see that, so you know if things are working properly or not
13:37 < colin__> That's exactly what I have. A EUB 9706 wireless N USB adapter, Ralink based chip (802.11 b/g/n)
13:37 -!- acuster [<email address hidden>] has quit ["Leaving"]
13:38 -!- squelos [n=squelos@85-170-117-94.rev.numericable.fr] has joined #ubuntu
13:38 -!- squelos [n=squelos@85-170-117-94.rev.numericable.fr] has quit [Client Quit]
13:38 -!- will__ [<email address hidden>] has quit [Connection timed out]
13:38 -!- jcape [n=jcape@41.sub-75-205-200.myvzw.com] has joined #ubuntu
13:38 -!- hubert_ [<email address hidden>] has quit [Client Quit]
13:38 -!- danielrmt [n=danielrm@189.59.187.25] has joined #ubuntu
13:38 -!- jose__ [n=jose@201.82.129.205] has joined #ubuntu
13:38 -!- dany_boy____ [<email address hidden>] has joined #ubuntu
13:38 -!- jMyles [<email address hidden>] has joined #ubuntu
13:38 < jose__> join #mapserv
13:38 -!- ravennium [<email address hidden>] has joined #ubuntu
13:38 < qwyeth> colin__, this device isn't a normal wireless adapter... it's designed to make configuration in windows easy; it seems that when you push the button to activate it, it's supposed to pop up something in windows that circumvents typical configuration steps
13:38 < qwyeth> that might mean that without the full-fledged windows driver you're hosed
13:38 -!- dany_boy____ [<email address hidden>] has quit [Client Quit]
13:38 -!- raf_ [n=raf@190.87.253.143] has quit [Client Quit]

After:
13:37 < sebsebseb> ctmjr: oh ok, well yes it will flood with peoples name when they leave or re join, but it could be useful to see that, so you know if things are working properly or not
13:37 < colin__> That's exactly what I have. A EUB 9706 wireless N USB adapter, Ralink based chip (802.11 b/g/n)
13:38 < jose__> join #mapserv
13:38 < qwyeth> colin__, this device isn't a normal wireless adapter... it's designed to make configuration in windows easy; it seems that when you push the button to activate it, it's supposed to pop up something in windows that circumvents typical configuration steps
13:38 < qwyeth> that might mean that without the full-fledged windows driver you're hosed

A combination of hiding joins/parts by default along with ...

I would like to propose a solution that is simple, will involve complex governance infrastructure an is something we could implement in a reasonable timezone.

We faced a similar problem with membership applications to the CC. The CC were getting bogged down in the volume of requests so we scaled up the infrastructure in the community and created three memberships boards, each service a region of the world.

In a similar vain I propose:

 * Let's create #ubuntu-europe, #ubuntu-asia and #ubuntu-americas and encourage our users to use their nearest support channel.
 * The IRC Council will govern each of these channels as official channels in the same way they do now.
 * We will write a tiny fix in Ubuntu that will detect a user's timezone at install time and auto-join the nearest channel.
 * #ubuntu will still exist but show a message when you join inviting you to join the nearest channel.

The benefits:

 * Only three channels for the IRC Council the maintain.
 * Limited development work involved.
 * Matches our regional approach to membership.
 * Channels are better matched to users - more people are likely to be available and awake.
 * We could potentially promote other regional resources in these channels such as LoCo Teams.

I would like to ask the IRC Council to draft up a blueprint to outline this change and we can then tighten the nuts and bolts and get a spec together.

I do not think splitting the channel is a good idea for much of the same reasons many others have expresed the same sentiment. Mainly separating the channels will divide those providing support and the people who wants to learn by just iddling there.

This sounds like a good solution to me.

I like Jono idea, but I would miss the cross-pollination of culture we get in #ubuntu. The one problem I see is people joining all the support channels and just asking the same question in all three channels.

As soon as you open X channels you are asking the people who offer support to split their focus across X channels.
Marek and Lorenzo's solutions are ideas that combined would make things better for the helpers and in so doing would help those who join the channel.

#ubuntu-reagional zone would be the place that was busy as it's TZ time came to it's usual IRC peak, and thus in my opinion (and without testing) very little difference would be seen in terms of quantity in conversation / scroll, now except that the TZ would be peaking in different channels assuming that people went where their TZ was.

Then you lose the cross pollination of helpers which is what grows people who are helping. It is the combination of skills that help these places work, dividing them will make them weaker.

A finite amount of helpers can't make more channels work, you just need a better irc toolchain, and I think the ones suggested above would be really helpful, perhaps someone could help LjL tune -meta and test it.

The way it used to work was that someone repeated a question that question got turned into a faq for the bot, and maybe a badly written wiki page that got attacked and cleaned up by the doc people, all of a sudden you had improved things.

Perhaps that may help swing the way you are all thinking. Remember you need buy in from both the helping community and the users to make it work, as users don't know / understand when they join initally what a PM you have just built a mountain before they start off. The idea is to smooth the end users path and allow them skill up to a fully capable helper, at least that that is how IRC has worked since I joined it back in the early 90's or else I have totally misunderstood something (which knowing me is possible ;-) ).

Anyway I hope whatever ye do works to improve it all around!

>
> #ubuntu-reagional zone would be the place that was busy as it's TZ time
> came to it's usual IRC peak, and thus in my opinion (and without
> testing) very little difference would be seen in terms of quantity in
> conversation / scroll, now except that the TZ would be peaking in
> different channels assuming that people went where their TZ was.
>
This was my first thought too, that the timezone convenience would already exist in #ubuntu, with only the local region being awake at any given point in time. You would still have one over-full channel, but now 2 mostly idle ones as well.

--
Michael Hall
<email address hidden>

On Fri, 2010-01-15 at 00:21 +0000, Paul O'Malley wrote:
> As soon as you open X channels you are asking the people who offer support to split their focus across X channels.
> Marek and Lorenzo's solutions are ideas that combined would make things better for the helpers and in so doing would help those who join the channel.
>
> #ubuntu-reagional zone would be the place that was busy as it's TZ time
> came to it's usual IRC peak, and thus in my opinion (and without
> testing) very little difference would be seen in terms of quantity in
> conversation / scroll, now except that the TZ would be peaking in
> different channels assuming that people went where their TZ was.
>
> Then you lose the cross pollination of helpers which is what grows
> people who are helping. It is the combination of skills that help these
> places work, dividing them will make them weaker.
>
> A finite amount of helpers can't make more channels work, you just need
> a better irc toolchain, and I think the ones suggested above would be
> really helpful, perhaps someone could help LjL tune -meta and test it.
>
> The way it used to work was that someone repeated a question that
> question got turned into a faq for the bot, and maybe a badly written
> wiki page that got attacked and cleaned up by the doc people, all of a
> sudden you had improved things.
>
> Perhaps that may help swing the way you are all thinking. Remember you
> need buy in from both the helping community and the users to make it
> work, as users don't know / understand when they join initally what a PM
> you have just built a mountain before they start off. The idea is to
> smooth the end users path and allow them skill up to a fully capable
> helper, at least that that is how IRC has worked since I joined it back
> in the early 90's or else I have totally misunderstood something (which
> knowing me is possible ;-) ).
>
> Anyway I hope whatever ye do works to improve it all around!
>

For cultural 'cross-polination' there's #ubuntu-offtopic, which I do visit
every now and again.

By dividing up the main channel into 3, it might be possible if we need to,
to refer users to channels more suited to their language.
For example, if someone is in the americas, it's probable that they speak
either english or spanish. If they're in asia, they're probably indian,
chinese, japanese, korean, or so on.

I think Jono's idea would be progress, but just as seeing chinese or korean
text in a channel is useless to me, seeing english text in a channel might
be nearly useless to someone in China. Operating systems and software are a
topic such that you probably need to get help in your own first language. I
tend to think that what ever we implement needs to do that with as little
end user confusion and time as possible.

There is already #ubuntu-cn and #ubuntu-it #ubuntu-loco this point seems to be lost on people.

If someone turns up from Italy and greets in Italian or someone turns up from .vn they get told about the correct channel via factoids in the bot.

Mostly though I see mutliple channels being generated for no real gain.

Before you reply to this please check out the list of channels available here:

Now how are three more going to help that?
They are not - and mostly people argue with their neighbours not people far away, I have seen not in the ubuntu space thankfully people from adjoining countries being very antagonistic towards each other.

There are filters for -ir -sa even .co.uk ;-) and so forth.
The point not being addressed is this.

As was said in Prague, I most likely have spent the most time bar almost anyone else on IRC in the last 15 years.
If such a beast was put in place you can expect to lose helpers faster, and don't forget that you are stressing those people who help. If someone needs native langauge support they will be directed to their loco.

The best other idea here would be to have a bot to welcome people and show them a wiki page that would show them how to ignore joins and parts.

Is the channel scrolling too fast for you to keep up, then please use $setting for your client - if it is still too fast ask your question and prefix it with the words too fast - someone may join you (no one is obliged) in #ubuntu-classroom to help with your issue.

Furthermore lurkers are your next generation of helpers.
Is there room for a project to tackle the logs for the last month and see what questions are being asked the most in that time, thus leading to a wiki page of FixMes This Month. at the end of the day perhaps the object is to show someone how to fix something, not learn how to code, just get their box running in a reasonable way.

If Ubuntu shipped a client that hid extraneous joins, parts, and the nicks
of lurkers by default, I think that just might suffice.

Continental channels? Oh good grief no. For the reasons others including those who do or used to manage users in the IRC environment on a daily basis have already desperately shouted no.

Block joins by default in config will cause confusion all of its own (newbies freaked out when someone disappears totally while talking to them without any indication whatsoever), but it's sure worth finally trying.

But it's definitely better than fragmenting a community that is already fragmented by the lingua franca. The english-speaking community would be really diminished under Jono's suggesion as it would result in UK/Za in .eu with thirty zillion european languages, US/Ca in with spanish/portuguese and so forth, and Au/NZ in with the 30 zillion asian languages.

You're really not going to improve the situation for Newbies of any country by making it harder for Americans to help the Brits, Aussies to help the English-speaking Italians or South Africans to help English-speaking Asians.

Hiding extraneous joins and parts doesn't mean hiding all of them. If
someone has talked within x minutes or addressed that user, it would show
when they leave, and probably when they come back.

That may sound easy enough, but getting the IRC clients to actually do that is technically difficult. Not to mention the overhead of maintaining several patches against several IRC clients.

Pidgin already has a plugin that does that except for the nick hiding..
 (It'd work just as well to sort them into an active and passive group and
make the passive nicks grey instead of colored in the room list and put them
on the bottom)

That's just one client, what about XChat/XChat-Gnome, Konversation,
Quassel, irssi?

Re: Terence's point about the irc clients, it's true. To get all clients to behave this way across multiple systems (how many newbies IRC from Windows/OSX because their ubuntu is b0rked?) is incredibly difficult. Technical solutions to social problems always are. It took a ages and lots of effort to get all the irc clients to use freenode's 8001 port as default (for the freenode/ubuntu server pre-sets) to stop the NAT exploits being such an enourmous burden etc.

... by which i mean "all the irc clients *in ubuntu* to use freenode's 8001 port"

Is a person who's a 'noob' is going to be using an irc client other than
what Ubuntu ships default?....

@ethana2

Two points.

1) It's not just 'noob's (as you put it) that use #ubuntu. I have used Ubuntu for 5 years and I still ask the odd question in there.
2) We have shipped multiple irc clients in the past including pidgin, xchat, konversation etc.

Quite often when someone asks for help in any other channel, they are
simply told to ask in #ubuntu. LoCo team channels will often try to
help, but for project channels people usually just get referred away.

Maybe if we encourage people to offer what help they can in these channels first (provided it doesn't disrupt a meeting or something) before referring people to #ubuntu, it would cut down on the amount of traffic coming there in the first place.

--
Michael Hall
<email address hidden>

On Thu, 2010-01-14 at 21:03 +0000, Mike Basinger wrote:
> I like Jono idea, but I would miss the cross-pollination of culture we
> get in #ubuntu. The one problem I see is people joining all the support
> channels and just asking the same question in all three channels.
>

Is anyone <else> considering what could be done at the local level to
make the use of IRC necessary in fewer cases? My suspicion is that the
lack of truly local LoCo's fuels the overcrowding of online support
channels like IRC. More locality in our teams and groups would mean more
people that can help others face-to-face... this bug may be related to:
https://bugs.launchpad.net/ubuntu-community/+bug/392986

Yeah, want to set up ubuntunebraska.info with Voice assistance support
with Flash -> XMPP and ditch irc for support altogether.

Would I be alone in thinking that in a FLOSS environment help without peer review is bad.
One of the things that happened in #ubuntu was a waterfall of useful information, and a prevention of bad habits.
All very well going to help, but you need to give good help. Other things that need to be considered is that there are those who will do nothing without help, and this was about making people aware that they can get machines running themselves with very little help.
(it has changed a lot in 15 years, forget about the last 5 alone which has been a huge step forward)

==>> I could be wrong :)

You know, switching from irc to a voice infrastructure would provide
good incentive to make the OS more support-friendly like OS X instead
of just telling people to type commands into their terminals all the
time. Since I provide support for my mom over the phone, it would be
very helpful to me for others in the ubuntu community to have the
barriers I face every week made clearer to them on a daily basis so
that I could have some hope of them getting resolved.

Also, while one must watch irc or hear annoying sound notifications
constantly, you can leave a mumble server running on a computer in a
room with a good microphone and just do whatever it is you do until
you hear someone ask something you think you might be able to help
with.
The main downside of this is that it would not automatically create
text logs unless run through a voice recognition system-- but maybe
Google can help with that?

Personally, I just want to be able to wear my bluetooth headset and
take "phone" calls over the internet from ubuntunebraska.info 24/7.
All I need is the proper software infrastructure.

I don't think a voice/video support system can scale in the way IRC can. How would it cope with tens/hundred of people asking questions simultaneously? Also, on IRC you'll see often people giving support to multiple people at once, that's just not possible with a non text-based system. IRC is not going to go away any time soon.

That's where locality comes in. Those people proving voice support
could be using irc as *their* support backend when google fails.
Plus, they're more likely to know how to file bugs and so on. Do you
really want every new user and their mom filing redundant and poorly
described bugs on launchpad? How accessible do you think irc is? I
remember it took me MONTHS just to figure out how to get on Freenode
at all. My friends only managed to get on because I showed them how.
I'm not expecting irc to go away, it has it's place -- but I'm not
sure I believe that it's place is end user support.

On Tue, Jan 19, 2010 at 3:07 PM, Terence Simpson
<email address hidden> wrote:
> I don't think a voice/video support system can scale in the way IRC can.
> How would it cope with tens/hundred of people asking questions
> simultaneously? Also, on IRC you'll see often people giving support to
> multiple people at once, that's just not possible with a non text-based
> system. IRC is not going to go away any time soon.
>
> --
> #ubuntu too noisy to be useful
> https://bugs.launchpad.net/bugs/392799
> You received this bug notification because you are a direct subscriber
> of the bug.
>

ethana2,

If your IRC client does not make it easy for you to join #ubuntu, you should probably report a bug against the client. That is not a bug in the channel.

I meant more registering a freenode username and all that

Juha Siltala <email address hidden> wrote:

>ethana2,
>
>If your IRC client does not make it easy for you to join #ubuntu, you
>should probably report a bug against the client. That is not a bug in
>the channel.
>
>--
>#ubuntu too noisy to be useful
>https://bugs.launchpad.net/bugs/392799
>You received this bug notification because you are a direct subscriber
>of the bug.

I poked one week's worth of #ubuntu logs with pisg in order to get an idea of the level of channel business. The logs are from the week of 11th to 17th of this month, retrieved from http://irclogs.ubuntu.com/2010/01/ . Joins/parts are filtered from these logs.

* The average number of active nicks per day is 759
* The average number of lines per day is 8028, or 5.5 lines per minute
* The variation between busiest and calmest hours is not dramatic, but you can see relatively more traffic somewhere between hours 02 to 04, and again between 19-21. I assume the logs use UTC (is this correct?)
* Saturday is slowest. I wonder why :-)

The effect of hiding joins/parts is quite dramatic: the unfiltered log from the 12th has 17200 lines, or 12 lines per minute.

The logs i used and the stats that pisg created can be found at http://people.ubuntu.com/~topyli/ubuntulogs-jan11-17-2010/

Hope this helps evaluate the business of the channel. Please point out errors in my method, I am not internationally celebrated for my quantitative research work. :-)

I've written a proof-of-concept program that might help... helpers sort through support questions better (although it's not of much use to the people coming in the channel for support).

It is a single PHP file, which can be downloaded from http://pastebin.ca/raw/1773175 (or http://pastebin.ca/1773175 for the syntax-highlighted code).

It does away with joins and parts, and generally presents the channels in a wholly different way from a typical IRC client. More information is in the comments at the beginning of the program (read them! there are configuration settings you need to change).

Feel free to give me any feedback about this program by email or by joining #metabot-client. New versions of the code will be posted in the topic of #metabot-client and #ubuntu-meta.

> That's just one client, what about XChat/XChat-Gnome, Konversation,
> Quassel, irssi?

Would it help to setup a webchat client, like freenode's, but that presents channels in a more readable way, like filtering join/part messages, and probably give the user a chance to join a LoCo channel if he wished so?
I feel that a webchat is something that a newbie would be more familiar with than an IRC client.

of course, only a 0.6-1% of the people that join #ubuntu uses freenode's webchat, so the helpfulness of this is debatable, but that's probably due to being greatly discouraged (you get redirected to other channel, have to wait, etc)