Group list fork - was OT :: Archive topped 11000 messages
Author
csswa
Post date
2002-04-01T08:41:56Z
--- In ib-support@y..., "Jason Chapman (JAC2)" <jason@j...> wrote:
The ideal situation is where:
1) Experienced members don't have to waste time sorting the wheat
from the chaff when providing group support. However, I've noticed
most EIBUs ('eeboos' <grin>, experienced interbase users) here are
quite happy to jump in now and again to answer basic questions that
qualify as RTFMs. If they have time, they're happy to deal with that
stuff, which is great.
2) NIBUs ('neeboos', new interbase users -- 'newbie' is too
perjorative) can post 'signpost' messages and any other message that
they could easily answer themselves if they took the time to RTFM or
search the net, and not be made to feel excluded. How can they feel
excluded when they have their own group! :-) I class 'signpost'
messages as messages from NIBUs who *will* eventually RTFM and get up
to speed themselves, but for now they are just excited and
overwhelmed and want to get there now Now NOW (Are we there yet? Are
we there yet?) :-) I confess to being this type myself.
When the time comes, splitting ib-support into two groups will
provide both the above. Let's say the hypothetical groups are called
IB-NEW-USER-SUPPORT and IB-SUPPORT. (I'll leave aside the issue of
switching 'FB' to 'IB'.)
The name itself will draw new users to the right list. It's here
that new users can be immediately signposted to the top-level
resources (ibphoenix, manual references, etc.). NIBUs who post new-
user-type questions to IB-SUPPORT can be redirected quickly and
politely to the new-user group.
The natural progression will be for NIBUs to do their groundwork in
ib-support-new-users, begin posting occasionally and then
predominantly to ib-support. EIBUs will no longer wade through banal
threads unless they choose to do so by visiting the NIBU group.
Perhaps even a roster system for EIBUs volunteering to monitor the
new-user group on a weekly basis!
So there's my pitch for forking ib-support. The worst thing about
being a newbie -- ahem, 'neeboo' -- is feeling like a freshman
physics student in a room full of NASA astronomers. You're a little
scared to open your mouth in case something stupid pops out
like, "Wow, mankind got to the moon and I can't even find the
cafeteria, hehe hehe, ah, mmmm..."
Regards,
Andrew Ferguson
> I was thinking how we could still encourage support and have a
positive impact for newbie's.
>
> It is so important to offer a good support forum for people who are
just
> coming to IB for he first time, a few RTFM's is often enough to put
people
> off, but it seems required for the dozens of Q's "which is
better... how do
> I.....", which make up much of the traffic. Most of these kind of
posts
> have little or no qualifying information at all.
>
> I love answering questions with answers or suggestions, but
replying with
> "what OS / version / number of clients / ......", just fluffs up
the
> forums.
>
> I thought of two tier groups, but this seems elite-ist (sp), it
would work
> on a "anyone post" group and an "invite only" group. People who
answer the
> anyone post group are invited onto the "invite only". The
meatiness of the
> questions and answers on the "invite only" group may make searching
archives
> easier.
>
> I had other thoughts about how to get people to search before the
ask,
> without having to be too forceful, this would really need a lot of
> moderation and marking message threads as stopped with a
reply "Have you
> searched these sources? list of sources".
>
> Don't get me wrong, the forum is way off from grinding to a halt,
but
> already I find myself block selecting 30 or so messages and marking
them as
> read, possibly missing a Q that I could answer and add some value.
>
> just my 2c's.
>
> JAC.
>
> ""csswa"" <csswa@y...> wrote in message
> news:a8720f+6lct@e...
> > ... which may require IB-support to split in two to better handle
the=20
> > traffic? Sometimes I wonder how some of the regulars here
(Ann,=20
> > Claudio and Helen spring to mind immediately) manage to provide
this=20
> > constant flow of online support and still get the food-on-the-
table=20
> > work done. As traffic escalates, this may become more of an
issue,=20
> > especially if the experienced members get to the point where they
no=20
> > longer have time to skim all posts and reply to those of
interest.=20=20
> > Growth itself isn't necessarily a bad thing, but poorly managed=20
> > growth is.