From Fedora Project Wiki

(add a section on naming)
(adding comments in line on these points; sorry to mix the for/against, but going inline seesm to make a better discussion at this point :))
Line 31: Line 31:
 
# Collision of names:
 
# Collision of names:
 
## this is what disambiguation pages and categories are for
 
## this is what disambiguation pages and categories are for
 +
##* Aren't disambiguation pages a PITA to maintain?  It seems a bit crazy to have to maintain yet another page, ''if'' there is a nesting solution that resolves most of it.  This was why I considered just one level of nesting for subprojects/SIGs, so the disambiguation happens as we go.  - [[User:Kwade|quaid]]
 
## are you kidding? Wikipedia is the greatest mix of multiple audiences on the internet, we're several orders more single-focused
 
## are you kidding? Wikipedia is the greatest mix of multiple audiences on the internet, we're several orders more single-focused
 +
##* The main site of Wikipedia is one single audience, yes; they may be looking for many different kinds of information, but they are all ''information consumers''.  As soon as a person decides to start editing Wikipedia, they are an ''information contributor'' and all the content they need for contributing is in a separate namespace ([[Help:Editing]], for example).  In the Fedora wiki, we mix both consumer and contributor information in the main namespace ([[FedoraProject]]), making it two different audiences.  We are pushing content such as the Help namespace in to the main search because such a large part of the audience are contributors who need to find that information in a regular search.  All mixed in one wiki means we have to consider slightly differently than the experiences of a single-audience wiki such as Wikipedia. - [[User:Kwade|quaid]]
 
## If you have a guide for end-users and a guide for contributors, just name one « User guide » and the other « Contributor guide ». That's more clear for everyone involved, including google
 
## If you have a guide for end-users and a guide for contributors, just name one « User guide » and the other « Contributor guide ». That's more clear for everyone involved, including google
 +
#* Don't get caught trying to solve this one example; I didn't spend a lot of time on thinking of it.  Naturally we want to use unambiguous titles, which is part of the reason we are trying to write up how to name pages.  But the situation is already here and will continue to be that we have two audiences who might need a document that has a similar name. - [[User:Kwade|quaid]]
 
# naming structure should not be similar to nesting without the visual clues. One of the main advantages of no-nesting is you can choose titles in natural text, not some random collation of keywords that's difficult to pronounce, remember and discover
 
# naming structure should not be similar to nesting without the visual clues. One of the main advantages of no-nesting is you can choose titles in natural text, not some random collation of keywords that's difficult to pronounce, remember and discover
 
# nesting …   
 
# nesting …   

Revision as of 13:53, 30 June 2008

The great nesting debate

Against

Stop (medium size).png
On nesting
I disagree with nesting except for pure utility pages. Nesting makes indexes on category pages very difficult and user-unfriendly. There are other ways to mark a page belongs to a group (such as categorization or branding).
  • good index with human-friendly article names and not nesting
  • bad index with nesting, human-hostile article names and bad sorting

-- nim

For

I don't disagree with the sentiment; I'm not clear myself what is right/wrong/best/worst. There is a lot of entrenched thinking that supports nesting, and to move away from that we need to address those ideas and needs. My biggest concerns are:

  1. Collision of names in the flat namespace as different subprojects have similar needs
    • In a single-audience (e.g. "encyclopedia readers" for Wikipedia) this is less of a concern; with multiple audiences, confusion can arise. For example, is the User_Guide for the end-user audience or the contributor audience? User of what? Etc.
  2. Naming structure is similary to nesting without the visual cues

Nesting is in place for a lot of sections, and since it isn't breaking search/indexing, we're at least going to need to take this in stages. It all comes down to the strength of the argument.

-- quaid

Against #2

  1. Collision of names:
    1. this is what disambiguation pages and categories are for
      • Aren't disambiguation pages a PITA to maintain? It seems a bit crazy to have to maintain yet another page, if there is a nesting solution that resolves most of it. This was why I considered just one level of nesting for subprojects/SIGs, so the disambiguation happens as we go. - quaid
    2. are you kidding? Wikipedia is the greatest mix of multiple audiences on the internet, we're several orders more single-focused
      • The main site of Wikipedia is one single audience, yes; they may be looking for many different kinds of information, but they are all information consumers. As soon as a person decides to start editing Wikipedia, they are an information contributor and all the content they need for contributing is in a separate namespace (Help:Editing, for example). In the Fedora wiki, we mix both consumer and contributor information in the main namespace (FedoraProject), making it two different audiences. We are pushing content such as the Help namespace in to the main search because such a large part of the audience are contributors who need to find that information in a regular search. All mixed in one wiki means we have to consider slightly differently than the experiences of a single-audience wiki such as Wikipedia. - quaid
    3. If you have a guide for end-users and a guide for contributors, just name one « User guide » and the other « Contributor guide ». That's more clear for everyone involved, including google
    • Don't get caught trying to solve this one example; I didn't spend a lot of time on thinking of it. Naturally we want to use unambiguous titles, which is part of the reason we are trying to write up how to name pages. But the situation is already here and will continue to be that we have two audiences who might need a document that has a similar name. - quaid
  2. naming structure should not be similar to nesting without the visual clues. One of the main advantages of no-nesting is you can choose titles in natural text, not some random collation of keywords that's difficult to pronounce, remember and discover
  3. nesting …
    1. isn't breaking search/indexing: you've not looked at the morass our category indexes are.
    2. is in place for a lot of sections … need to take this in stages. Taking it in stages means having clear targets so you can stage the pages you modify (and touch each of them once). Taking it in stages does not mean having to pass many times on each and every wiki page, changing one bit at a time.

-- nim

On naming

  • sections and page titles should follow the same conventions, since a page is just a standalone section
  • separate pages can be reorganised in sections within a single page, and a single page can be spit in separate pages over time
Idea.png
Capitalization
Capitalize first letter of first word, leave the rest lower case: "Like this".
  • this is a great convention, then why all the User Guide, Package Maintainer Generic Job Description examples?
  • re-structuring nested pages is not just replacing slashes with spaces
  • re-structuring CamelCased pages is not just adding spaces between collated words
  • re-structuring is re-ordering and re-wording titles in short natural language forms, with no gratuituous casing and without skipping articles and other parts of a natural language sentence
  • Example: SIGs/FooBar/Join
    • no Foo_Bar_SIG/Join
    • yes Joining_the_Foo_bar_SIG
    • yes Joining_the_Foo_bar_special_interest_group
  • Example: EPEL/PackageMaintainer/GenericJobDescription
    • no EPEL/Package_Maintainer_Generic_Job_Description
    • yes Generic_job_description_of_EPEL_package_maintainers
  • Example: SIGs/Foo/Meetings
    • no Foo_SIG_Meetings
    • yes Foo_SIG_meetings
    • yes Meetings_of_the_Foo_special_interest_group (will sort at M)

-- nim