Help talk:Wiki structure

The great nesting debate

Against

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
      • 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

Capitalization
Follow Wikipedia's Manual of Style on capitalization

• 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
  • yes --Ian Weller 04:39, 2 July 2008 (UTC)
• 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
  • very yes --Ian Weller 04:39, 2 July 2008 (UTC)
• Example: SIGs/FooBar/Join
  • no Foo_Bar_SIG/Join
  • yes Joining_the_Foo_bar_SIG
    • Agree --Ian Weller 04:34, 2 July 2008 (UTC)
  • yes Joining_the_Foo_bar_special_interest_group
    • No Certain technical usages are already used globally in Fedora, not just on the wiki. Keep the "SIG" standard. Use this as an example for other pages, as necessary. --Ian Weller 04:34, 2 July 2008 (UTC)
• Example: EPEL/PackageMaintainer/GenericJobDescription
  • no EPEL/Package_Maintainer_Generic_Job_Description
  • yes Generic_job_description_of_EPEL_package_maintainershttps://fedoraproject.org/wiki/Help_talk:Wiki_Structure#On_naming
• Example: SIGs/Foo/Meetings
  • no Foo_SIG_Meetings
  • yes Foo_SIG_meetings
  • yes Meetings_of_the_Foo_special_interest_group (will sort at M)
    • No Too lengthy, see #Naming comments --Ian Weller 04:34, 2 July 2008 (UTC)

-- nim

Naming comments

• From quaid:
  • Say outloud these two page titles: "Docs Project meetings" and "Meetings of the Docs Project". They are both accurate and sound fine, for native language speakers. In English, it is more likely that the shorter, more declarative form ("Docs Project meetings") is going to be used; many would call that version "more natural", perhaps because of the English speaker's habit of removing articles (the) and prepositions (of).
    • One way to explain why to use this style of naming, rather than calling it "natural language forms", say they are "easier to understand for non-native readers" and "easier to translate."
    • Another good argument is that having pages with intrinsically accurate titles means they sort properly on the category page. As you point out, all the meetings then fall under "Meetings of Foo-20080630" and sort chronologically etc.
    • * Agree --Ian Weller 04:28, 2 July 2008 (UTC)
  • What is the recommended approach for User: namespace pages and drafting? There is a wiki tradition to use the nesting under a user's name as a sandbox/drafting location, e.g. User:Kwade/Packaging_How-to_(draft).
    • Keep this tradition --Ian Weller 04:28, 2 July 2008 (UTC)

Discussion on both

Nigel's Views

These two suggestions are too similar, and I'm for and against different parts of each of the suggestions, in particular:

• Nesting is bad, BUT...
  • It does serve a purpose, i.e. whats wrong with having _ALL_ EPEL pages prefixed by EPEL/

-- nim: it renders all category indexes useless for users. Please check some category indexes. Indexes are a major tool for users to navigate a wiki morass (which ours is like the others), with nesting they're next to useless.

• • For our purposes a depth of 1 is 'sane'.
• CamelCase sucks in MediaWiki
  • The examples of 'good' links in my opinion are bad, they are too long, and as a result become unreadable

-- nim: abbreviations are only readable to their authors. They don't index (in Google) well. They're very hard on non-native English speakers

• • The simple act of adding spaces where they would have been removed would fix just about everything...

-- nim: obviously I disagree

--Nigel 08:48, 1 July 2008 (UTC)