Help talk:Wiki structure

The great nesting debate

Against

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
   • Can we be sure that all instances will continue to work without being unreadable?
     • Docs/Beats/Kernel => Docs_Beats_Kernel is a bit strange; that can be reimagined (Relnotes_Beats_Kernel)

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
   2. are you kidding? Wikipedia is the greatest mix of multiple audiences on the internet, we're several orders more single-focused
   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
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

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