From Fedora Project Wiki
(moving discussion from the main page) |
(New section: The great nesting debate) |
||
Line 1: | Line 1: | ||
{{admon/caution| On nesting | | {{admon/caution| On nesting | | ||
I disagree with nesting except for pure utility pages. Nesting makes indexes on category pages such as [[:Category:Fonts_SIG|this one]] very difficult and user-unfriendly. There are other ways to mark a page belongs to a group (such as categorization or [[:Template:CompactHeader|branding]]). - [[User:Nim|nim]]}} | I disagree with nesting except for pure utility pages. Nesting makes indexes on category pages such as [[:Category:Fonts_SIG|this one]] very difficult and user-unfriendly. There are other ways to mark a page belongs to a group (such as categorization or [[:Template:CompactHeader|branding]]). - [[User:Nim|nim]]}} | ||
== The great nesting debate == | |||
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: | |||
# 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. | |||
# 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. |
Revision as of 06:05, 29 June 2008
The great nesting debate
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:
- 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.
- 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)
- Can we be sure that all instances will continue to work without being unreadable?
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.