FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 06-10-2008, 12:07 PM
Tim Niemueller
 
Default Wiki URL Structure (Proposed Change #2): flatten page hierarchies

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@niemueller.de> www.niemueller.de
================================================== ===============
Imagination is more important than knowledge. (Albert Einstein)

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 06-10-2008, 12:24 PM
"Peter Lemenkov"
 
Default Wiki URL Structure (Proposed Change #2): flatten page hierarchies

2008/6/10 Tim Niemueller <tim@niemueller.de>:
> 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!

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 06-10-2008, 12:27 PM
"Peter Lemenkov"
 
Default Wiki URL Structure (Proposed Change #2): flatten page hierarchies

2008/6/10 Nicolas Mailhot <nicolas.mailhot@laposte.net>:
> 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!

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 06-10-2008, 04:06 PM
"Karsten 'quaid' Wade"
 
Default Wiki URL Structure (Proposed Change #2): flatten page hierarchies

On Tue, 2008-06-10 at 16:27 +0400, Peter Lemenkov wrote:
> 2008/6/10 Nicolas Mailhot <nicolas.mailhot@laposte.net>:
> > 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 Categoryraft_Documentation, then moved to
Categoryocumentation 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
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 06-10-2008, 04:06 PM
"Karsten 'quaid' Wade"
 
Default Wiki URL Structure (Proposed Change #2): flatten page hierarchies

On Tue, 2008-06-10 at 16:27 +0400, Peter Lemenkov wrote:
> 2008/6/10 Nicolas Mailhot <nicolas.mailhot@laposte.net>:
> > 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 Categoryraft_Documentation, then moved to
Categoryocumentation 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
_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
 
Old 06-11-2008, 02:42 PM
Kevin Kofler
 
Default Wiki URL Structure (Proposed Change #2): flatten page hierarchies

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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 06-11-2008, 03:21 PM
Kevin Kofler
 
Default Wiki URL Structure (Proposed Change #2): flatten page hierarchies

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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 06-12-2008, 08:36 AM
"Karsten 'quaid' Wade"
 
Default Wiki URL Structure (Proposed Change #2): flatten page hierarchies

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
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 

Thread Tools




All times are GMT. The time now is 09:01 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org