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".