Great to see this come up. I didn’t know about the
subpage support until now! While I agree that we should continue to improve
our use of categories, I have a big +1 for this convention because of the
automatic bread crumb trail. One of the biggest problems we had with our
wiki pages is that users find it hard to navigate all the pages related to a
topic (e.g. Mylyn), and the automatic bread-crumb trail addresses that. If
others are in favor of the subpage naming I would like to convert all of the Mylyn
pages (bug 210295).
I also think that having consistency here would be helpful. So the main question
I have is whether the top-level pages should be projects, or subprojects?
In other words, should the Mylyn pages be titled:
Mylyn / Contributor Reference
Tools / Mylyn / Contributor Reference
I vote for (1), because I believe that most consumers don’t
care about the internal organization as much as they care about which project
they are in. Also, a flatter structure can be easier to use, and subprojects
can move between projects. I figure that we can make the project
structure clear with categories (i.e., Mylyn is a subcategory of Tools).
The template approach Boris proposes looks helpful too, we may
try that as well.
[mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Nick
Sent: Saturday, November 17, 2007 9:49 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Wiki
When I first started writing
wikis, I tended to use the [[Category:...]] convention to group pages into
obvious categories like Releng, Java, EMF, Modeling, FAQ...
I still do that, but having discovered the 'automatic breadcrumb' effect of
creating subpages using "/" in titles, I've started renaming pages to
use that new convention, as it provides a sense of page-to-project ownership
and navigation that the categories don't provide.
Also, category nesting is a powerful way to create component or subproject
Personally, I recommend using both. Oh, and as Remy taught me a while back, if
you need to redirect a page to another page (and can't do a Move because there
are already two existing pages, or because you want to have a landing page
direct to a Category ), just do something like this:
Of course one aspect of naming that Remy didn't mention is the over-verbose
page titles like "Eclipse Web Tools Platform Project" when "Web
Tools Project" would work just as well. ;-)
On Nov 17, 2007 12:17 PM, Remy Chi Jian Suen <remy.suen@xxxxxxxxx> wrote:
I know a wiki is supposed to be open and free, but I think
standardizing a couple of things here and there would be helpful and
make it look a lot more uniform. The primary issue I have is with the
naming convention of pages. There are probably other things that needs
to be changed too, but I think that this inconsistency looks bad and
is kind of annoying.
There are a couple of projects that have adopted the subpages concept
by using slashes in their page names like...
...and then we have those that go about with the full article name like...
GMF Development Guidelines
Equinox p2 Getting Started
ECF Ganymede Roadmap
Mylyn Contributor Reference
...and next, we have RAP and Bug Day kind of doing its own thing (as
far as I know) with limiting the use of spaces (for no technical
reason, mind you, since spaces in titles are perfectly valid)...
...and BIRT that's decided to use suffixes for identification purposes
on a few of their pages like...
Contributing Examples (BIRT)
Logging The Events - Show the Typical Log Stack (BIRT)
...and finally, we have some pages that come out of nowhere with no
There may be other naming conventions that are being employed, but
since there are so many Eclipse projects and so many wiki pages, I
have only presented a sample of what I have seen while clicking
I would personally vouch for the first option of using subpages
(PDT/FAQ) as I feel that that would make organizing things a little
easier and makes it immediately clear as to what a page is under.
Does anyone have any opinions or thoughts about this, what are your
preferences? Does anyone even care or am I making this inconsistency
problem sound bigger than it really is?
cross-project-issues-dev mailing list