On Sat, 2008-11-08 at 08:55 -0800, Akemi Yagi wrote:
> <snip>
> Many of you on this mailing list may still remember the longish thread
> regarding the writing of a HowTo rpmbuild article. At that time, I
> quoted several forum posts to demonstrate the fact that we repeatedly
> *type* the same answer each time a new person asks the same question.
> This was because there wasn't really a good single point of reference
> we could use and the best way of responding was to write the whole
> thing out (again and again).
>
> At lease for me, the most propelling reason for creating a new article
> is to make things easier for people helping new users rather than to
> expect new users to read it.
>
> And the article/subject Ned is proposing is indeed worth writing.
> With so many people switching from Fedora and other distros, we have
> been having so many occasions in which we should explain what an
> enterprise class OS (thus CentOS) is about.
Agree 100%. I just want to mention that the OP, combined with your post,
really opens a whole can of worms, when considered in the light of
things such as what you mention and the assumption that the user base is
growing.
I thought it might be useful to the project to think about this. If not,
just ignore this please.
In projects I've seen in the past, the addressing of things such as
_effective_ FAQs, proper indoctrination of new users (in ML, fora and
chat rooms) into the _basics_ of the project are usually delayed until
the swelling volume forces action to be taken just for sanity/survival
of the "hittest". :-) Although these things weren't ignored, they are
often considered, effectively, in isolation. Consideration or
estimations of user-base constituency, user-base size, project growth,
degree of confusion experienced by new users, ... often miss the mark.
The folks who try to actively help get hit the hardest with repetitive
questions. the most frequent symptom of the need for a re-examination.
Often these don't make it into a FAQ or other standard frequently
referenced place because of a lack of a FAQ coordinator or maintainer or
a lack of effective support from the rest of the group in proposing new
potential FAQ entries.
Further, the new user often doesn't review the FAQ (or other resources)
until someone gets really ticked and says something like "It's in the
FAQ - GO READ IT". Some mild coercion when a user signs up for an ML,
forum or chat room could help alleviate that situation.
If the FAQ is well maintained, organized, supported by appropriate
proposals, and somewhat forcefully introduced to new sign-ups, ML and
fora support folks might see reduced repetition and could also use it,
via a quick inclusion of a URL, to expeditiously answer some of the oft
seen issues.
However, this is an isolated stab at a larger problem, IMO. The number
of informative articles on the wiki can be expected to continue to grow.
There are also many links in the list archives that reference outside
resources, such as blogs or other web sites, that answer many questions.
This list has already entertained a thread that proposes some
"consolidation" of activity in the fora and mailing lists. Unresolved,
IIRC.
The basic issue here is that in a project with a user base as diverse as
CentOS (regardless of a strong skew of the profiles towards one or
another group, like administrators or programmers, or ...), there are
too many portals to obtaining information:
Planet/People/.../FAQ/Forum/ML/homer page "Information" drop-down, ...
Combined with search engines, all this conspires to overwhelm a new
user, especially of the user is in a time-constrained environment where
a quick resolution is needed.
If my sense of the growing popularity is correct, I suggest that now is
a good time to start a thorough discussion about the information
infrastructure and ways of ... "encouraging" new users to use the
infrastructure _and_ reduce the number of possible paths that exist to
finding needed information.
A combination of "single path" access to all these information
resources, a new sign-up "introduction" to this path, a dedicated
support team to keep the components current and a commitment of all
those who participate to constantly propose (and generate/maintain where
possible) these components should be considered.
If something results from this thread, I volunteer to help as I can,
although most of you realize that my skills are limited and dated. But I
still can learn relatively quickly. It's just that I seem to fit the
profile I read long ago: younger folks grasp, retain and more quickly
recall details while older folks tend to grasp, integrate and apply
concepts more quickly without being as nimble about the details of
things.
>
> Akemi
> <snip sig stuff>
--
Bill