573
edits
User:Bigstones: Difference between revisions
Jump to navigation
Jump to search
→A plan for a reorganization of the wiki
(Created page with "Working on LIPY scenery, randomly maintaining the wiki. ---- {{WIP}} == A plan for a reorganization of the wiki == === Introduction === I've been consulting the wiki fo...") |
|||
| Line 20: | Line 20: | ||
However this is not helping in finding the articles, let alone having an overview of them. In fact, see this: [[Airport data (apt.dat) update]]. This article will be lost in [[Category:Core development projects]] and more so in the totally flat [[Category:Scenery enhancement]]. | However this is not helping in finding the articles, let alone having an overview of them. In fact, see this: [[Airport data (apt.dat) update]]. This article will be lost in [[Category:Core development projects]] and more so in the totally flat [[Category:Scenery enhancement]]. | ||
I'm not sure if the wiki allows for more | I'm not sure if the wiki allows for more independent categorizations to exist for one article,<ref>Please keep reading and you'll see what I mean.</ref> but in general I think that a tree structure would fit and help in maintenance. A tree structure would force all (most?) of the categories to be a subcategory of another. | ||
==== Why? ==== | ==== Why? ==== | ||
This way, you know for sure what an article belongs to, and | ;Maintainability: This way, you know for sure what category an article belongs to, and it is very easy to find by lurking into the categories. That is, ''every article has its own, well defined place''. This will help avoid duplication and scattering of information (I've seen a lot of that), that lead to unmaintainability, outdated contents and makes it harder for the reader to find this outdated information, which leads to confusion and frustration and grinding teeth... we've all been there I'm sure. | ||
The category pages have this great gift of being self maintained and | ;Portals: The category pages have this great gift of being self maintained and can be a perfect reference. This is not true for the right columns of the Portals. They of course need some expertise to know what are the most basic articles for a beginner, nobody is fully expert. By checking the proper category, the maintainer can see if there are articles that might be important and that he/she didn't know about. The articles that | ||
;Early benefits: But mostly important, in the early stages of this reorganization, by building this tree and giving each article one single category we'll be able to find articles that should actually be merged, or split, and any other instance of duplicated information. Then, we can | |||
==== How? ==== | |||
Well, to do all this, there sure is need of tools. So far, the only one I've found [https://www.mediawiki.org/wiki/Extension:CategoryTree Extension:CategoryTree] that could be useful. | |||
In general, one should be able to have an organic view of current category tree and do some "drag and drop" and "rename" with articles and categories as you would with files and directories. One could create temporary categories, where to put things that look similar, then maybe finding they need some sub-categorization or that those articles should all have the same category. Slowly things would get the shape of a tree. | |||
The main categories are already there. The current organization of the portals is an excellent guideline. I've recently seen [[Category:Scenery enhancement]] where the subcategories are just ready, only they're done "by hand" and not yet applied. That's doing the right thing with the wrong tools. Many categories suffer from this flatness, probably because of the already mentioned use of categories as tags. Another noticeable example is [[Category:Howto]], but again, there are many. | |||
==== Isn't one category per article a too strict limitation? ==== | |||
Yes and no. In fact, some articles might be useful in a couple of far related categories. An example is given by [[Modeling - Getting Started]] and [[Howto:Lightmap]] (as most of the effect/animation related articles). These articles clearly belong to a couple macro-categories: [[Category:Aircraft enhancement]] and [[Category:Scenery enhancement]]. But there's also [[Category:Modeling]] and [[Category:Effects]] (well... pretend it exists). | |||
This is the problem of orthogonal (i.e. independent) categories. On one axis, there seem to be the area of application (scenery, planes) and on the other particular technologies and techniques (Nasal, effects, modeling, ...). If the wiki allowed a "cartesian product" between chosen categories <u>''when searching''</u>, we could actually "tag" the articles, one tag per axis, and there would be means, when browsing categories, to see directly articles that have these tags combined. | |||
To put it graphically:<ref>I renamed the categories: why enhancement if most articles talk about creation?</ref> | |||
<pre> | |||
* Scenery development * Scenery development | Modeling (and viceversa) | |||
* Aircraft development Cartesian * Aircraft development| Modeling " | |||
==============> * Scenery development | Effects " | |||
* Modeling product * Aircraft development| Effects " | |||
* Effects | |||
</pre> | |||
Even if this was possible, it would need a ''very carefully'' selected set of axes and categories. | |||
The alternative, though, doesn't look so bad in this wiki, because the number of "axes" of categorization is very limited. One should simply replicate in the category tree what the cartesian product would do.<ref>I had to make those categories better, because scenery modeling might refer to both objects and terrain, while for aircraft it could be 3d model or physics model</ref> | |||
<pre> | |||
* Scenery development * ... | |||
* Scenery object development * Object Modeling | |||
* Object Effects | |||
* Aircraft development * 3D modeling | |||
* Modeling * 3D model effects | |||
</pre> | |||
FIX THIS DIAGRAM | |||
=== Remarks on development articles === | === Remarks on development articles === | ||