On Tue, 2008-06-10 at 16:27 +0400, Peter Lemenkov wrote:
> 2008/6/10 Nicolas Mailhot <firstname.lastname@example.org>:
> > I'd like to propose another wiki URL structure change.
> > In the past years, with the previous wiki, there was a drive to build deeply
> > nested page hierarchies. For example Foo SIG was hosted in SIGs/Foo, and its
> > contents put yet another level deeper ie SIGs/Foo/Subject
> Yes. We need to flatten this mess.
> > As you can see, replacing file hierarchies by categories work pretty well,
> > except all the indexes are user-hostile for items not moved to the wiki root
> > (which I have not done yet). So I'd like to do the last step and flatten
> > completely my SIG page hierarchy.
> Vote for this!
Before the move and since, we've been discussing this issue amongst the
wiki gardening crew. We'd like to see new pages adhere to a new
structure, and to have groups begin moving existing pages to a new
We're working on the details of the structure at [[Help:Wiki
* Flat namespaces:
Docs/SecurityGuide => Security_Guide
Get_Involved_Guide in Category
raft_Documentation, then moved to
ocumentation when complete
One thing we've been tossing back and forth is how to deal with the two
distinct audiences to the wiki: end-users and contributors.
One argument is categorize and create ways to keep from duplicate naming
problems. For example, adding (SIG) on the end of SIG pages. Another
idea is to use Namespace:Foo, that is, create a new MediaWiki
"Namespace" that sorts content into a separated part of the wiki. This
removes the content from the index for the site Namespace
. This might make sense in some cases, e.g. QA: for all
the QA test plans. I don't think we want to sequester SIG or subProject
content in that way.
One reason we used directory-like hierarchy in the past was to make it
"easier" to find pages. MediaWiki has a good search mechanism, but
AFAICT it needs spaces "_" in page names to find words in titles.
Regardless, it's going to do a better job of helping people find content
than the MoinMoin search did.
Another view point is that we don't want to hide contributor content
from end-users, but it would help if we, for example, put a badge on
end-user focused pages so it was clear "this is for help with using
Fedora." That can be easily done with a template, cf. [[Template:Move]]
for an idea of how it works.
Karsten Wade, Sr. Developer Community Mgr.
Dev Fu : http://developer.redhatmagazine.com
Fedora : http://quaid.fedorapeople.org
gpg key : AD0E0C41
Fedora-infrastructure-list mailing list