IRC channel organization proposal

I'm definitely supportive of migrating #drupal to a sort of landing-page support channel, but I worry about integrating the MANY other #drupal-whatever channels into #drupal-contributors just because #drupal tends to get pretty noisy as it is, and adding even more traffic to that could be pretty rough.

How about #drupal for support, #drupal-contrib (instead of contributors) for module/theme development, and #drupal-core for core development?

How about:

• #drupal for general chat & support (replacing #drupal-support)
• #drupal-core for discussing development of the main system
• #drupal-dev for module development, etc.

Any exclusive dev (or any sort of exclusive) channel is largely scoffed at. We want people to be able to migrate easily to become a contributor.

The problem with #drupal-dev was mentioned in the discussion, and it was said (rightly so IMHO) that it would suggest it is about _developers_ only, scaring away theme contributors, documentation writers etc, thus #drupal-contrib.

+1 on #drupal as landing channel
+1 on #drupal-community as development discussion channel

Well, I'm not sure that there is a need for two rooms — one for working on core and another for working on contrib. One of the fun things is that you get to mix and match, learn development for contrib for a while, and later expand that activity into working on core. Or vice-verse. Many questions are really for both — like: how do I roll a patch?

Plus, activity discussing core goes up during certain times, and contrib goes down (like now). Soon core discussions will drop, and contrib discussions will explode, so I'm not sure that a separation is really necessary.

More importantly, however, I want to strongly advocate for *not* choosing words like "dev" and "core". They are geek-centric, and imply that the rooms are only for people writing php code. 2009 has been the year of recognizing that it takes php coders, AND visual designers, AND front-end developers, AND documentation-writers, AND newbie testers, AND user-experience designers, AND people of all skill-levels and internet-focuses to make Drupal great.

An IRC chat room name that is too specific (like "#drupal-geeks-who-know-php-at-a-mastery-level") is not going to serve us as well as a broader name.

I like #drupal-community best.
#drupal-contributers is also nice and broad (not only about coders).

I still maintain a 2 tier system isn't going to work. #drupal will be a combination of what #drupal is now and #drupal-support and it will be slammed. The people who currently are fleeing #drupal will definitely flee and many of those who find #drupal manageable now will be scared off as the volume goes through the roof. So you'll end up with #drupal being a newbie zone, #drupal-community being for those who actively give back, and no place for more experienced people who are working on their own sites.

A 3-tiered system would add an area for those people and hopefully have a low enough noise level that higher level devs will at least spend part of their time there helping out.

While I realize that anyone at any level can start being a contributor, and we certainly don't want to discourage anyone, I think it's far more likely that someone who is already developing on their own site will make the leap to being an active contributor in the short term than someone who comes in wanting to know how to log into their site after they disabled the login block. If we leave those people in the cold because they are neither newbie enough nor experienced enough, I think that would be a big mistake.

Michelle

I only lurked in on the discussion, but I think this proposal is a good one.

I don't like the idea of one channel for core developers and one for the rest. Having everything related to Drupal development (incl. UX, doc, etc.) in one channel sounds better than splitting the community in two groups.

As for the name of the channel, I too like #drupal-community. It doesn't scare away non-technical community members and it covers all aspects of the channel.

Would this change affect all topical channels? (#drupal-ubercart, #drupal-dojo, #drupal-geo, etc.) And would one still be able to use e.g. #drupal-dev and #drupal-infrastructure to discuss issues with less background noise?

I don't see the advantage in further sub-dividing the general contribution channel into core and contrib, and in fact see such divisions as problematic. They create a barrier (both physical and psychological) of "you must be THIS good to belong here." It also makes it really challenging to keep a pulse on all of the activity going on, and to know where to direct people who want to get started helping out.

Should it turn out that #drupal-contributers/contributions/community/whatever is too busy, we could always revisit this proposal and look at handling overflow. I imagine temporary #drupal-$topic channels will naturally occur just as they do now when a specific topic comes up that needs some deep discussion among several people.

I do also want to point out that although this proposal indisputably matches the natural expectations of IRC users, it represents a fundamental shift in how our community functions, and we need to take this shift very seriously.

Up until this proposal, #drupal has been designated the central hub of activity for core and contrib development, patch reviewing, architecture discussions, community initiatives coordination, etc. People new to Drupal were directly thrust into this buzzing beehive of activity, filled with very smart people doing very awesome things as their first taste of the Drupal community. We've had much cross-over from "regular" Drupal users to contributors directly as a result of the fact that the people busy building Drupal are very visible, and the barrier to get started is effectively stating, "That thing you're working on sounds awesome! How can I help?"

When you move these people doing cool things into a sub-channel, and turn #drupal into a support channel, there are some fundamental shifts that will inevitably happen:

1. Major contributors who used to frequent #drupal since it was this central hub of activity are going to leave and isolate themselves in #drupal-X (though one could argue that this has already begun for some). This isn't a rudeness thing; most of us are just way too busy to handle newbie support questions, and since #drupal-X is only questions related directly to contributing, "regular" developers are going to lose a major resource that was formerly available to them, and an important on-ramp to crossing the threshold to a contributor.

2. New users' first impression of the Drupal community won't be this awesome network of cool people doing cool things. It'll be screen-fulls of questions like "How do I make a blog?" In fact, most of the cool people doing cool things won't be present at all (see #1).

3. Whoever helps out with support in #drupal will need to make very concerted, conscious efforts to ensure that the migration from "user" to "contributor" continues to happen, since it will no longer happen organically. I am dubious of this happening, despite all the best intentions in the world, and anticipate that the tap of new, eager contributors will be slowed down to a mere trickle compared to what it once was after the contributor community is relegated to a sub-channel. And you thought it was hard to find patch reviewers now, eh...? ;P

4. The entire process of fostering new contributors gets much more difficult when there is a perception (real or imagined) of "us" (we lowly people who are trying to figure Drupal out) vs. "them" (the people building Drupal... and who by the way are constantly making our lives difficult, and how the hell come they aren't in here helping me and... etc.). The former channel set up with #drupal being both a developer support and contributor channel much more fostered the culture of "we", and we will effectively lose this culture (since it's relegated into a sub-channel you have to explicitly go looking for) once this change occurs.

I've given up ever winning this battle of continuing to keep Drupal's contributor community front-and-centre, so the only option left for me is damage control at this point. I want to ensure that people are aware of what we're effectively getting into as a community by making this shift, and that we have volunteers lined up to do what they can to combat its adverse effects.

Let me put in a plug for three rooms. I think we have enough traffic, and enough diversity of experience and needs, to support them. I know there's a concern about creating "silos," but I think having more rooms will in fact increase movement between rooms. Here's why: If we try to roll everything into two rooms, very few people will have the time or energy to hang out in both rooms. But if we have beginner, intermediate, and advanced rooms, more people could be in two rooms at once. For example, I could hang out in intermediate and advanced, and I'd be able to mentor future core contributors asking "how do I add a field to a form?" The people asking "how do I add a field to a form?" would feel comfortable helping out in the beginner room. So we'd get overlap, which is hugely important. When that FAPI newbie is ready to write a module, there'll be experienced devs right there in intermediate to invite him upstairs.

I personally would argue for #drupal to be the intermediate room; I think that's the right level of experience to do triage (and let's be honest; whoever gets #drupal is going to have triage to do). Plus that's where community talk belongs, and the intermediate room should be comfortable for everyone. And the intermediate room would still be a place where a lot of webchick's "awesome things" would go on. But most important, I think, is that we not try to cram what is now essentially three levels (-support, -dev, and #drupal) into two.

@chx: but at the cost of new users in general?

+1 ksenzee @ #12.

I think the current 3 tied system of #drupal, -support and -dev works well, although in reality, I've seen people & discussions in -views or in PM that probably belong in -dev, and I'm told no one really uses -dev. So the trick seems to be just getting people to actually use -dev.

+1

3yrs later... lets hope something happens this time around.

We can just bow at what webchick says, and continue the effort to keep #drupal to be the potpourri of all development and #drupal-support the "rest". It won't be easy but it's likely she is right. It would be awesome, however, if real channel moderators would appear. Not that I want to make #drupal moderated, dont get me wrong but if we do this then we need to direct traffic and make newcomers understand what's going on and what can and can not be expected etc. Currently, we have a few people who occassionally does that. If there would be a bunch then I would be more comfy with that.

I'd agree w/ Michille/ksenzee too about needing at least 3 channels with graded focuses - as best I understand, we are essentially proposing the following shift:

#drupal-support -> #drupal
#drupal -> #drupal-community
#drupal-dev -> #drupal-contributors

However, I also think webchick has a very important point of the perception of activity/energy by someone who drops into #drupal. It leaves the impression that the community is very active. Other projects' channels you can try - generally not much is happening.

So, I think the tradeoff is whether people looking for support naturally end up on the first try where they expect to find help - i.e. #drupal, as opposed to being ignored or told to go to #drupal-support (sometimes then perceiving this as as rude rebuff).

Quite frankly, I think a bigger issue is that it would be nice to have some "staff" always in #drupal-support vs. the channel naming being the real problem. I'm not sure where we find that cadre of eager no-noobs to be around to provide support, so it might be useful see if accepting support questions in #drupal whiel trying to keep some of the community activity there would be effective.

@pwolanin, noone suggested that. The proposal was #drupal-support => #drupal , #drupal => #drupal-contributors (or community). The need for a third channel was raised but I see no good names for it.

But all this is rather pointless because some of us make an effort for years to make #drupal a nice place and then all we get is becoming the butt of a joke for it. I am out of this discussion for good and it will be some time before I get back to any Drupal IRC channels (how long I can stay away I know not but I got seriously hurt tonight).

From reading the comments, I've seen the following trends:
1. People support the idea. A lot. In fact, no one is against it.
2. Some people (roughly even split) want to create a third a channel. While I'm biased, I haven't seen any strong arguments against it.
3. We can't seem to figure out a name for this third channel.

So. Let the argument begin. It's pointless to come up with a name if the channel won't exist anyway, so let's first figure out if it will exist and then figure out what to call it.

I missed the irc discussion (although just now reading a bit of backscroll), but have been thinking a lot about this recently, and was part of an earlier discussion with chx, stephthegeek, Michelle and others.

So for a while, I've been thinking that #drupal-dev and #drupal-usability could be merged (no, seriously), since they serve exactly the same purpose - you roughly know who might be in there, they're quiet, conversations can happen slowly over a couple of hours without getting lost, a lot of the same people are in both channels. I'm not in #drupal-docs often but it seems like that serves a similar purpose when I have been in it.

So #drupal-contributors/#drupal-community seems to be that channel, which seems fine - better than having to join 4-5 obscure channels just to follow what's going on, many of which have the same people in anyway.

However if that leaves #drupal for everything else, then that potentially gets really busy, and it's possible #drupal-community - if it holds all 'on-topic' discussion would also be really busy, but then it'd still be possible to make temporary break out channels for specific things if it gets too much - like #drupal-i18n has been at times.

The problem with support questions isn't that they're support questions - sometimes it's quicker (and friendlier) to answer a support question than it is to type "Druplicon, tell $person about support.", however sometimes people are going about things completely the wrong way, or have bizarre requirements you'd run a mile from if you saw them in an rfp, and you can't always tell this when the question is first asked - and it's going to take a good 20-30 minutes if not a lot more to get any kind off sanity happening. If both code and clicking support is in #drupal, then that might make it a bit hard to manage imo - in which case #drupal-support could maybe live on as an overflow channel for in-depth support discussions?

The thing that concerns me, is that I like to answer the quick one-liners when I have time, but the random complicated/stupid ones are both too time consuming and hard to ignore. The idea with the channel topic change which I think prompted this discussion - is that if you turn up in #drupal with "I found a bug in a contrib module, how do I best report this" - that's contributing. "I can't install Drupal 7 alpha 1 on godaddy" is also contributing (or can easily be turned into contributing). But "Should I use preg_replace() to remove the read more link on the recent blog posts block." is a support question. The proposed two channel split seems better than having both #drupal and #drupal-support being support channels (one for code, one for clicking), which is how it currently feels sometimes, but I both share webchick's concerns about the new contributor funnel and chx's about burning long-term contributors out.

Either way I'd be up for trying this out, and will un-join all the sub-channels if we give it a trial run. It's likely that we won't be able to figure out what the 'third channel' might or might not be until something's been running for a month or two.

Well, I was the one saying we should have 3 and my general idea was this:

#drupal-support: Keep it. It's quite active and there's a lot of newish people helping brand new people and so on. I think it actually functions quite well for entry level support.

#drupal: Keep this similar to how it was before the recent rule change. Any dev talk is ok, whether for your own site or contributing back. General chit chat and socializing ok if it's not interrupting anything. General mish mash of Drupal folks hanging out and learning from each other. People asking basic, non dev related support requests are gently asked to move to #drupal-support. This is a good middle ground for people who are not yet contributing but may make that leap if given the support they need. If we keep the basic site admin questions out, the noise level will hopefully be low enough that most of the more advanced devs will be willing to hang out there.

#drupal-community / #drupal-contributors: Everyone is welcome here but questions are expected to be about core/contrib work. People asking basic PHP questions or who are clearly working on their own site are gently asked to move to #drupal or #drupal-support as appropriate. This channel would be more work focused and avoid too much chit chat and off topic conversations. Similar to #drupal-dev now but opened up more to include non development items such as docs and UX and also intended to be actively used, not just overflow.

Michelle

I'd be happy with #23 - basically that's just consolidating -dev/-usability/-docs into a single channel - if it can replace those three (and possibly more), there are clear paths to it from #drupal, then that's less silos than what we have now, and less tabs in xchat for me. It also means more cross-pollination between the docs/usability/core coding teams which is what gets missed when there are subject-specific overflow channels.

Thanks for not havign that discussion again.

+1 for moving the main support channel to #drupal.

The main issue with having a small number of IRC channels is that there are so many people that everyone always figures someone else will help, or feels that someone else has a higher level of knowledge so they're better off keeping quiet.

I was perpetually asking questions in the current #drupal and I have received about 3 answers ever, about 1 of which was genuinely useful, so I just gave up, choosing #drupaluk instead where there were fewer people and therefore, I believe, more chance of getting decent help. I honestly think it's because there are just so many people in #drupal.

A lot of this discussion is naturally biased because its contributors are the people who use IRC for discussing core or documentation work. It would be better to focus on an outsider's perspective, someone who is not part of the "Drupal inner circle", and someone for whom, currently, IRC is quite a weak tool.

I think the way to improve things is by committing more people to IRC support, instead of trying to constrict the current inadequate resources to fewer channels in an attempt to compensate.

@killes: I'm not normally one to counter a status change by you but this is an active discussion by the community. If you don't wish to take part, feel free to ignore this issue but the community is having this discussion and "won't fix" is premature.

Michelle

I think the way to improve things is by committing more people to IRC support, instead of trying to constrict the current inadequate resources to fewer channels in an attempt to compensate.

We can't "commit" anyone to do anything. No one is getting paid to offer support on IRC, forums, etc. and we certainly can't order volunteers on how they "need" to spend their time. People will ultimately do whatever is fun/interesting/scratches an "itch" for them, and answering basic support questions can either be heaven or hell, depending on your perspective.

That said, I have absolutely no problems with a group of people who genuinely enjoy giving support on IRC taking steps to better organize themselves so that there is more constant coverage of IRC channels. But there is no grand overlord of IRC who's going to make people do this. It needs to happen organically.

About Michelle et al's proposal to keep #drupal as the "intermediate" channel, I have a hard time understanding what exactly we gain from that. Keeping #drupal as a development support channel and #drupal-support as the user support channel doesn't address the "IRC users the world over expect the #$something to be a user support channel and feel they're getting the brush-off when they're told to go somewhere else" problem, nor does it address major contributors such as Earl getting too burnt out, since he and people like him will continue to "hide" in #drupal-X and not in #drupal once it becomes pure support (developer support is still support). So it seems like the worst of both worlds, really... we'll continue to have new users' first impression that they're getting the brush-off, the cool people doing cool things will still be shuffled off into a corner somewhere instead of front-and-center where they currently are now, and developers who need support will have a reduced pool of people from which to draw it... am I missing a cluebat?

I guess a counter-proposal could be:

- #drupal: The "lounge" area. Ask questions, talk about patches that need review, whatever.
- #drupal-dev: For in-depth development support questions if they're starting to over-take the main channel.
- #drupal-support: For in-depth user support questions if they're starting to over-take the main channel.
- #drupal-themes: For in-depth theming/design support questions if they're starting to over-take the main channel.
- #drupal-contributors: For in-depth community-related discussions if they're starting to over-take the main channel.

Ideally:
- Everyone hangs out in #drupal, but can safely ignore discussion most of the time if they need to focus, since it's pretty "light"; just one-off questions, idle chatter, that kind of thing. But the phrase "Let's go to #drupal-XXX and talk more about that." is much more common.
- The people who enjoy giving support can hang in #drupal-dev or #drupal-support or #drupal-themes, depending on their range of skills.
- The people who create Drupal, manage its community, work on core or contrib, translations, do documentation, usability improvements, etc. etc. all hang out in #drupal-contributors and that's a quiet, "focused" channel with no support questions.
- Organic break-out rooms like #drupal-i18n or #drupal-project or #drupal-learn-how-to-patch happen as needed, but are announced in the main channels whenever discussion is moving there so that others can take part if they want.

I guess it's a matter of perspective. I don't see moving people to #drupal-support, if it's done nicely, as brushing them off. During the active hours in US/Europe time zones, the channel is very active and lots of people giving and getting support. If it's phrased as "That's the place where people can help you" rather than "go away and don't bother us", I don't see a problem.

That said, it's the multi tiered concept that I'm pushing and I'm not married to any particular channel names. My main concern is that we get as many experienced devs as we can to hang out where the dev questions are and that is a lot less likely if we lump dev support and admin support together in the same channel and drive the noise level through the roof. So #29 would be fine by me as well.

Michelle

Gerhard has pointed out that by this issue being in the Drupal.org infrastructure queue, it's pinging the infrastructure team via e-mail on every reply, and since it has nothing to do with maintaining servers, doesn't belong there.

I'm moving to the "Drupal" project for lack of a better place. Please don't move it back.

Well I see Michelle's as simply consolidating the 5 or 6 drupal-* channels which already exist, which various working groups have made because the traffic in #drupal is too much, into the new unified channel proposed, but without initially changing anything else.

If this channel pulls /some/ traffic away from #drupal, then it's possible that #drupal will effectively become the catch-all support channel, and #drupal-support gradually whittles down to 'really really in-depth support when #drupal is too busy' like #drupal-dev kinda is now. And we'd end up with essentially the two channels originally proposed - but it'd be a gentler, more gradual approach - whereas shutting down drupal-*, opening #drupal-new-cool-channel and leaving #drupal as a free for all is going to be shock treatment. Shock treatment might be good or bad, but it's a major shift.

While I'm not 100% on any of the solutions, I think the characterisation of #drupal and #drupal-support as two support channels is correct, and have felt this way for some time - just one is for code and one for clicking. #drupal is sometimes also used for working, usually when webchick is in there though due to the #drupal-dev boycott, but that's almost ancillary at this point. There needs to be a place for getting work done, ideally it'd be nice to be able to follow that working channel without being glued to the pc all day i.e. actually being able to catch up with backscroll.

Also we need to remember this process has been going on for years, not just with irc.

The first couple of years of I used Drupal, the forums and development list were both used for getting work done. Look at the names on this forum post from only three years ago http://drupal.org/node/84014 - two of those people now stay out of #drupal 99% of the time, only Michelle continues to post on the forums. It took me about a year from then to give up on the forums, use the issue queue for discussion, then join irc. In the following three years I joined groups.drupal.org then largely gave up on it a year or so ago, similar for planet unless a blog post is linked from elsewhere, and I put the development list on filter a few months back when I reaised I hadn't seen any development discussion on it for several months. All Drupal development discussion now happens in irc and the issue queue, with occasional bits of activity in blog posts and twitter, it wasn't that way three years ago.

However, the community still has a decent flow of new contributors, despite the fact that a large number of people working on core or contrib modules have abandoned the forums, development list etc. - it took me two years to get on irc and actually talk to the cool kids in real time, people with a technology background might jump on first thing, but many more will look at forums and mailing lists like I did which have much less coverage than the irc channels for sweeping people into contributing.

For me the strength of a dedicated working channel is that it'll be documented somewhere and possible to find it - whereas all the sub-channels aren't as well documented, not to mention back channels like twitter etc. - at least if it's official there's a route there, and that should be less clique-y rather than more.

Cross posted :(

The more recent comments are moving in what I think is a better direction. I've never really been happy with the -support breakout, in part because for whatever reason -support tends to be much more basic questions than #Drupal.

A common problem I run into is that when *I* need support on something, it's usually some highly complex Views question or similar. But it often doesn't require code. Since it's non-code and for my own site, that makes it -support. But anyone who could actually answer such a question is in #Drupal or #Drupal-Views (the latter of which is clearly marked as not a support channel), not #Drupal-Support. So even those "inner circle" type people are ill-served at times. :-)

chx is correct, though, that #Drupal is going to be the "landing zone" for new people, no matter what we do. Fighting that is a waste of time.

Rather than a beginner/intermediate/advanced breakout, a more web-like structure makes more sense, I think. #Drupal is the "central hub" where stuff starts. Small questions of any type can go there, including casual banter. If the discussion gets long or the channel is busy, break out to a BoF room. And then we have a *small* number of "standard BoF rooms". Whether that gets called -dev, -community, -support, or whatever is less critical. The important part is that #Drupal becomes OK for anything small and not in-depth, but then we can split stuff off as needed. That means "go away and ask in -support" becomes "that's going to take more than 30 seconds to answer, let's move it over to -support". Ibid for "we need to figure out this algorithm, let's move over to -advanced-stuff (or whatever it gets called)."

Cross-posted with catch. Sounds like we're talking in the same direction.

#34 makes a lot of sense. The only pitfall I see is that we need the smart people to be waiting (or willing to come along) to the "advanced support breakout channel". Otherwise, the person who was getting help in #drupal will move over there and the conversation will stop. If there's followthrough to those channels, then I think this will work fine.

Michelle

Crell's #34 sounds like #29 with different words. Seems like we might be approaching a consensus here.

@webchick: Yes, I didn't claim it was original. :-) It means replacing the "support?" factoid with "Hm, that's a bigger question. Let's move to #Drupal-Support. See you there."

I like #29 for the reason that it encourages everyone to hang out in the same channel, and only break of for lengthy conversations. Having all great minds in the same place definitely seems like the right idea, instead of segregating the community by topic.

Another problem right now is that #drupal-support is often packed with tons of people asking questions, and even if there are a good 5-10 people answering questions, they just roll by too quickly and by the time you've formulated a possible answer, a good full screen of questions has rolled by. and I only see this getting worse as more people start using Drupal and finding themselves in need of support.

The proposal of making #drupal the general channel (and thus where the support questions would originate) will most likely leave the channel seriously flooded at times and I don't considering asking a good 10-20 people to move to #drupal-support as a feasible option. If they were all using single-channel clients, it would look almost like a netsplit (but parts instead of quits)

So even though this proposal might fix a different issue, beware of the ones you might be creating or making worse...

Far too often I see people running off to #drupal-nl (Dutch channel, with max 10 users of which 90% are idle all the time...) because the main support channel is flooded and they feel they receive guidance much quicker in this small channel full of idle people. Why? I'm not sure, I guess it's because everyone in that channel is surprised to see it light up with activity...

Also, you really shouldn't rely on people reading an IRC channel topic, because it turns out nobody does that... ever :(

@suetje: So what is your counter-proposal?

+1 I've been campaigning for this for a while. What I hear is:

1. #drupal handles some support now, we change the canned response and make it more friendly. Involved or stupid questions should be deflected elsewhere (#drupal-pit-of-unrequited-support-doom).

2. #drupal-x is for in-depth topical discussion / sub communities. I kinda like that, would be nice to get Druplicon on at least some of them (drupal-media for instance doesn't have it).

Okay, #1 just makes sense because it will be where 99% of people go when they need help. #2 makes some sense to me, but I think the issue here is just volume, so it's a balance between over/under fragmentation.

I'm in favor of this proposal.

A couple of suggestions / ideas:

Consult other successful projects who have dealt with this. PHP, Apache and wordpress come to mind. Hehe, btw I joined #wordpress for a minute to see it:

helpplease: eyecool`zZzZ this is the code
[10:24am] helpplease:
[10:24am] helpplease:
[10:24am] helpplease:
[10:24am] helpplease:
[10:25am] helpplease: INSERT_YOUR_PAGE_HERE what page do I put

Awesome.

Like @pwolanin said somewhere up there. This isn't really a question of how we name stuff, it's a question on where someone can get help starting w/ Drupal and the resources available. Bottom line:

"There are way more people trying to uncover the mystical WTF we all understand to be Drupal than we are around to help them (4 free)."

Let's solve this problem.

Here are a couple ideas (perhaps they are already done):

1. Build a page of paid support providers - link to it from an IRC canned response. If they are all too big, a market exists, and someone will fill it.

2. Build a consortium, get the Drupal Association and/or sponsors to pitch in money to hire a full time support person / newb herder in IRC. Seriously, we just did the whitehouse, I think we can scrap together the dough.

3. Make it a requirement of Summer of Code students to "person" IRC for some amount of time per week.

4. Add a feature to Druplicon. If a nick is new to Druplicon, it PMs the user with some info that would help them be effective in IRC.

5. Add another feature in Druplicon to prevent silo'ing. Someone in #drupal-x can cross post to #drupal. So if a lively discussion about api.drupal.org switching off of DoxyGen (PLEASE!) is happening in #drupal-contrib (or whatver), someone can do:
Druplicon tell #drupal that We are talking about improving our api docs by using something better fitted to our language of choice - PHP.
and people in #drupal would see the message with a link to #drupal-contrib.

k, there's my 2 bits.

-J

#43

1: http://groups.drupal.org/available-for-hire

2. Even if we get the money, I don't know if we have anyone that knows Drupal well enough that would be willing to subject themselves to IRC support full time. :)

3. Interesting idea. Only works in the summer, though.

4. I like that idea.

5. I don't know if we really need the bot for that... Seems easy enough for someone in both channels to say it.

Michelle

I only make it onto IRC about once a month so I have no idea why I'm even commenting here, but anyway :)

I like #29 a lot as well, but just a minor nitpick:

- #drupal: The "lounge" area. Ask questions, talk about patches that need review, whatever.
- #drupal-dev: For in-depth development support questions if they're starting to over-take the main channel.
- #drupal-support: For in-depth user support questions if they're starting to over-take the main channel.
- #drupal-themes: For in-depth theming/design support questions if they're starting to over-take the main channel.
- #drupal-contributors: For in-depth community-related discussions if they're starting to over-take the main channel.

Which of these channel names is different from all the others? Answer: The last one. Whereas the others are named based on the topic of discussion, "#drupal-contributors" could be taken to imply that you're supposed to be a member of some kind of group before you're welcome there. I think a more topic-focused name would be better, something like "#drupal-contribute".

re #45:

1. Contractors is not the same as support and training. I'd like to really have a focused link of where you can go to pay money to *learn* not just pay someone to do it for you.

2. I think there are a lot of people who would give Drupal support for money. At least, I hope so since Acquia's model depends on it and it seems to be working thus far :) Also, it does not (should not) be one person. Perhaps a rotating group, but the important part is PAID. I'd love to do it once or twice a month if I could get paid for it.

@44 #2

Didn't DrupalCon DC make a $200,000 profit for the DA ? I don't think any con attendee would object to ~30% of the profits going to pay an IRC support person.

Add me to the list of people who thinks being paid to do IRC support would be pretty sweet.

Let's not take this issue off-topic, please. If someone wants to write up a proposal to the Drupal Association to put paid IRC support as a line item on the 2010 budget, feel free, but that is a completely separate discussion from our IRC channel policy and can be coordinated on groups.drupal.org or elsewhere.

Sounds like this has pretty broad support at this stage. I'm not really sure what to do to mark it "fixed." I guess we'll mark it "RTBC" for 48 hours and then call it good?

If you have objections, please state them along with a counter proposal.

I've just put #drupal-contribute on autojoin.

Oh, wait. We still need to figure out the name of the place where people will be who are working on stuff related to Drupal.org.

Seems like the options proposed were:

a) #drupal-contributors
b) #drupal-contribute
c) #drupal-community

If we make #drupal-community a channel where you can only talk if you are doing something on drupal.org itself, then it's sorta saying "If you're not here, you're not part of the community" which seems rather exclusionary. It's also not clear at a glance what the channel is for. So I'd rather one of the contribut* options since it makes this clear.

David's point about the verb makes sense too, so #drupal-contribute works for me. Confirmed with catch on IRC that it worked for him, too.

So. Proposal is #29, except that #drupal-contributors => #drupal-contribute.

To make it happen just adjust the support factoid and change the autojoin message and topic. Easy. You do not need me for either.

So we want to try this right?

#drupal -> lounge, say hi, quickie support and contribute questions, anything.
#drupal-support -> in depth support discussions
#drupal-contribute -> in depth core/contrib/d.o. related discussion

I like this for another reason too. I'm actively avoiding -support as it is at the moment even though I know it's good to keep in touch with what the Drupal WTFs are for those new to it. I expect to be keeping an eye on the new #drupal though. It will be important to maintain a professional working environment in there, if u no wut I meanz, k thx.

Let's try this.

@chx: We need you to register the channel, don't we?

Michelle

I love the idea of making it officially ok in #drupal to ask quick questions. I run into the same issue that Crell has (I have a fairly advanced, on-my-own-site, clicky question, and nowhere to ask it), plus I think many of us already often follow the "it's ok to answer a short question in #drupal without sending someone to #drupal-support" rule. It's less work to type in a five word answer than send someone to another channel and explain it there ;)

So a big +1 from me!

@webchick: I don't really have one right now, I just wanted to make sure it's being taken in account that at times there is a lot of ppl requesting support and this will only grow

Well I have upgraded channel topics, the #drupal entrymsg and registered #drupal-contribute . I presume we need to spread the word now.

Okie doke then. Marking as fixed.

We should probably do some kind of front page announcement on this too. Though maybe that's a bit dangerous. ;)

I think we should give it a couple of days to bed in before a large scale announcement - and have #drupal irc channels ever been announced on the front page?

However someone should probably update http://drupal.org/irc