Re: Wiki URL Structure (Proposed Change #2): flatten page hierarchies

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2008-06-11 at 14:42 +0000, Kevin Kofler wrote:
> Nicolas Mailhot <nicolas.mailhot <at> laposte.net> writes:
> > So I'd like the authorization for interested groups to stop trying to use the 
> > tools the way they were not intended, kill the nested deep hierarchy mess and 
> > move pages to the wiki root.
> 
> Sorry, but I really really don't like this idea. :-(
> 
> I like how everything relevant to the KDE SIG is under SIGs/KDE, we know who's 
> responsible for those pages and we're sure not to trip on anybody else's page 
> names that way. I think the (directory) tree structure clearly indicates who's 
> reponsible for what, e.g. Packaging/* is FPC's domain, SIGs/KDE/* is KDE SIG's 
> domain etc.
> 
> One big flat namespace works well for projects like Wikipedia where everything 
> is free for all, but in Fedora, we have subprojects, which should have their 
> own namespace. (Yes, everyone with a wiki account is free to edit pages in most 
> directories, but there's still one group which is responsible.) Mediawiki 
> namespaces such as KDE:Foo might work, but I don't think they were really 
> intended to be used in this way, AFAICT they're intended to represent special 
> pages such as Image:* or Talk:* instead.

They also do not appear in the default search index.  That is a main
reason to be careful what we put there.  I doubt we want to hide any of
the content you are talking about.

I'm not personally against the nested directory-like structure; it is
similar to how my brain stores information, so I can recall wiki URLs
and such fairly well.

However, we used that structure in Moin for pragmatic reasons that
should be reviewed in light of how MediaWiki works.

We should review if that scheme is still as useful as before, and if it
can be replaced with a better scheme.

For example, if you put every KDE SIG page in the [[Category:KDE SIG]],
you may have gained the exact same value as nesting page names (making
it easy to find and maintain an area of the wiki).  Plus you may have a
new set of cool things you can do because of the categorization.

There are other ways to designate that a group is sponsoring a certain
page.  One we discussed is a "badge" that says, "You are encouraged to
edit this page to make it better; if you have any questions, please
contact the page sponsors, the Fonts SIG."

We want to encourage people to edit pages.  Does having pages in nested
namespace make people feel as if, "Packaging/Foo must be owned by
Packaging, I better not touch this page"?

Finally, there is the situation with the search index.  One of the PITAs
of Moin Moin search is that a keyword for the title is always expanded
as if from a wildcard search.  You get back a ton of pages, with the
relevant one buried in the middle.  If you guessed the wrong word, good
luck in the page turning up.

By having spaces in names, MediaWiki allows *us*, the thinking humans,
the chunk the longstringofwords into something sensible.  Maybe we're
lucky and MediaWiki considers a '/' to be a chunk separator.  But in my
usage, I've found the MediaWiki search to be better, especially where it
can find the actual word amongst the 13,000+ titles in the index.

- Karsten
-- 
Karsten Wade, Sr. Developer Community Mgr.
Dev Fu : http://developer.redhatmagazine.com
Fedora : http://quaid.fedorapeople.org
gpg key : AD0E0C41

Attachment: signature.asc
Description: This is a digitally signed message part

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux