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>