[CentOS-docs] New User Wishes to Contribute

Tue Oct 6 19:45:47 UTC 2009
Brian Mathis <brian.mathis+centosdocs at gmail.com>

On Tue, Oct 6, 2009 at 2:53 PM, R P Herrold <herrold at centos.org> wrote:
> On Tue, 6 Oct 2009, Ed Heron wrote:
>
>>  It appears that the people who are preferring the more restricted content
>> guidelines are saying they will accept content separation.  But having 2
>> separate content systems seems redundant.  Is there a way to have a section
>> (directory) of the wiki that is core and an expanded section?  This might
>> satisfy both sides?
>
> Goodness -- wiki.centos.org and wiki.projects.centos.org is
> too hard or better somehow than wiki.centos.org and
> wiki.centos.org/projects/ where './projects' content carries a
> 'this content is not as carefully vetted' disclaimer?
>
> The second approach sounds like more of a slam than living in
> a 'projects.' sub-domain to me.
>
> A refactoring of the personal homepages will have to happen in
> any event, and perhaps we should simply have a './personal/'
> in the main wiki and move all such into it ... but this then
> carries the expense of refactoring all the 'at the ./' point
> documentary narrative down a level as well.  ACL errors will
> be harder to avoid as well
>
> By carrying two wiki, we avoid that workload, and can have a
> self-serve model for getting commits in the 'projects.' one,
> and the moderated approach on the vetted one.
>
> My $0.02
>
> -- Russ herrold


All of this debate is dancing around the real issue, and that issue is
how the project defines itself.  That definition should be arrived at
by both the project maintainers and also the community of users.  The
way I see it, there are 2 main choices:

1) Run the project with a 1-way push model where all the participants
are vetted and push out software, documentation, etc... out to all of
the users.  This places all of the burden on the project maintainers,
but the end result is potentially higher quality documentation and
product.  This seems to be the general model followed right now.  One
cannot really contribute until going through the approval process, but
you make sure that each page has an owner and and the quality is
(theoretically) better.

2) Follow the currently more popular "community" model that is in use
in other OSS projects.  That means the wiki is generally open to
anyone with an account.  This model would yield a larger community of
people willing to contribute, at the cost of potentially lower quality
content (however, I don't not believe that will actually be the case).
 This model would be a shift in approach from where the project
currently seems to be focused.


The model for #2 has an escape valve, which is that all of the messy
"community stuff" can happen in the wiki, while the "official" stuff
that has been discussed here would live on the actual centos web site
outside of the wiki.  If you just so happen to use wiki software to
run that "official" part of the web site, then that should not be
called "the wiki".