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

[Nicolas Mailhot]

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

I've noticed while trying to clean up my auto-converted SIG pages that mediawiki
**really** wants to use a flat page hierarchy, with categories used to group sets of pages
(not surprising given its wikipedia roots; an encyclopedy hierarchy is flat).

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.

For example:

- SIGs
+ Category:SIGs
+ SIGs -> Category:SIGs (redirection)
+ Special_Interest_Groups -> Category:SIGs (redirection)
- SIGs/Foo
+ Category:Foo SIG (in Category:SIGs)
+ SIGs/Foo -> Category:Foo SIG (redirection)
+ Foo_special_interest_group -> Category:Foo SIG (redirection)
- SIGs/Foo/Subject1
+ Subject1 (in Category:Foo SIG)
+ SIGs/Foo/Subject1 ->  Subject1 (redirection)
- SIGs/Foo/Subject2
+ Subject2 (in Category:Foo SIG)
+ SIGs/Foo/Subject2 ->  Subject2 (redirection)
- SIGs/Bar
+ Category:Bar SIG (in Category:SIGs)
+ SIGs/Bar -> Category:Bar SIG (redirection)
+ Bar_special_interest_group -> Category:Bar SIG (redirection)
- SIGs/Bar/Subject3
+ Subject3 (in Category:Bar SIG)
+ SIGs/Bar/Subject3 ->  Subject3 (redirection)

I've already done some work in this direction for the Fonts SIG:
http://fedoraproject.org/wiki/SIGs/Fonts
http://fedoraproject.org/wiki/Category:Fonts
http://fedoraproject.org/wiki/Category:Font_wishlist

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.

Regards,

-- 
Nicolas Mailhot

 Créez votre adresse électronique prénom.nom(a)laposte.net 
 1 Go d'espace de stockage, anti-spam et anti-virus intégrés.

[Tim Niemueller]

Nicolas Mailhot schrieb:
>  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 
I like the paths, as they are the structuring element everybody is used
to from his home directory. I'd rather keep it. I specifically don't
like the Category:... links, especially not how it was done in the Fonts
SIG example.

	Tim

-- 
    Tim Niemueller <tim(a)niemueller.de&gt;      www.niemueller.de
=================================================================
 Imagination is more important than knowledge. (Albert Einstein)

[Peter Lemenkov]

2008/6/10 Tim Niemueller <tim(a)niemueller.de&gt;:
>  Nicolas Mailhot schrieb:
> > 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
>
>  I like the paths, as they are the structuring element everybody is used
>  to from his home directory. 
Using only paths are old and quite obsolete way to structure blobs of
information - categories (read - labels) are better.

We need flat structure with necessary amount of tags/categories. Take
a look at Wikipedia or remember when you last time tried to add
"Genre" to your audio-file when you're constrained to add only one :).

Note that pages in wiki aren't files - they just pages and they can
exists in many different categories.

Using paths will render us to multiple issues with duplicating pages
(huge number of redirections), many dupes while searching etc.

Home directory is very bad example since many files there are not
duplicated instead of wiki.
-- 
With best regards!

[Peter Lemenkov]

2008/6/10 Nicolas Mailhot <nicolas.mailhot(a)laposte.net&gt;:
>  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!

-- 
With best regards!

[Karsten Wade]

On Tue, 2008-06-10 at 16:27 +0400, Peter Lemenkov wrote:
>  2008/6/10 Nicolas Mailhot <nicolas.mailhot(a)laposte.net&gt;:
>  > 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
structure.

We're working on the details of the structure at [[Help:Wiki
Structure]]:

http://fedoraproject.org/wiki/Help:Wiki_Structure

* Flat namespaces:
  Docs/SecurityGuide => Security_Guide

* Categories:
  Docs/Drafts/GetInvolvedGuide => 
     Get_Involved_Guide in Category:Draft_Documentation, then moved to
Category:Documentation 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
(FedoraProject:).  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
-- 
Karsten Wade, Sr. Developer Community Mgr.
Dev Fu : http://developer.redhatmagazine.com
Fedora : http://quaid.fedorapeople.org
gpg key : AD0E0C41

[Nicolas Mailhot]

Le Mar 10 juin 2008 18:06, Karsten 'quaid' Wade a écrit :

>  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
>  structure.
>
>  We're working on the details of the structure at [[Help:Wiki
>  Structure]]: 
One problem is the conversion left the wiki in a sorry state, so wiki
authors need to fix their pages now. I at least can not wait for the
[[Help:Wiki Structure]]: page to be finished, the fonts SIG wiki was
not operationnal anymore, and I've not finished repairing it.

So, since I'm doing changes now anyway, could you please review the
current fonts SIG state, and suggest eventual modifications before I'm
done? Because I firmly intend to spend time away from wiki gardening
once I've returned my wiki perimeter to a correct state.

-- 
Nicolas Mailhot

[Kevin Kofler]

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.

        Kevin Kofler

[Nicolas Mailhot]

Le Mer 11 juin 2008 16:42, Kevin Kofler a écrit :
>  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, 
Fine for you :) I didn't ask for the permission to move your pages, I
asked the permission for interested groups to move theirs. If the old
way works better for you, stick to the old way, just let me use the
new one.

My interest in the new way is purely pragmatic, spending several days
fixing up old-way pages (with a rawhide browser) was an eye opener. I
want as much stuff as possible automated to avoid going through this
mess again in the future. Automating in mediawiki means categories,
thus I'll use categories.

-- 
Nicolas Mailhot

[Kevin Kofler]

Nicolas Mailhot <nicolas.mailhot <at> laposte.net> writes:
>  Fine for you :) I didn't ask for the permission to move your
> pages, I
>  asked the permission for interested groups to move theirs. If the old
>  way works better for you, stick to the old way, just let me use the
>  new one. 
That's fine with me. :-)

>  My interest in the new way is purely pragmatic, spending several
> days
>  fixing up old-way pages (with a rawhide browser) was an eye opener. I
>  want as much stuff as possible automated to avoid going through this
>  mess again in the future. Automating in mediawiki means categories,
>  thus I'll use categories. 
Just FYI, pywikipedia can mass-edit pages which match regexes such as 
SIGs/KDE/Meetings/[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9] (that's how I 
fixed the transcript links which all got broken by the migration).

        Kevin Kofler

[Karsten Wade]

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

[Paul Howarth]

Karsten 'quaid' Wade wrote:
>  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"? 
Unfortunate example. At least on the old wiki, Packaging/* had ACLs 
preventing anybody outside the packaging committee from making changes 
there, and if that's not the case in the new wiki, that's probably not 
by design.

Paul.

[Karsten Wade]

On Thu, 2008-06-12 at 09:41 +0100, Paul Howarth wrote:
>  Karsten 'quaid' Wade wrote:
>  > 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"?
>  
>  Unfortunate example. At least on the old wiki, Packaging/* had ACLs 
>  preventing anybody outside the packaging committee from making changes 
>  there, and if that's not the case in the new wiki, that's probably not 
>  by design. 
Correct, unfortunate example that I picked randomly.  The ACLs continue
to be in place, as they are on e.g. Legal.  Just substitute any other
example that fits:  SELinux, Art, Ambassadors, DocsProject, etc.

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