User:Bigstones/Essay:A plan for a reorganization of the wiki

Note to the readers: having now an idea of the standards of the three of you, I'll cut a lot of obvious things. If you're curious, or not one of the three, see also the previous version.

I've been consulting the wiki for about a month now, mainly on the topics of scenery, modeling and effects. I really feel there's need of a reorganization, maybe in other areas too. Although this might sound like a complete overhaul, this probably has a smaller impact than I expect, because I know a limited part of the wiki and a quick review of the rest shows it's not so far from what I'm talking about.

Sorry if I'm too direct. Better wiki -> better FG -> better playtime. (lol)

Restructuring the categories into a tree

I see that categories are used as tags, that is, they're combined so that the combination gives the idea of an article's real, specific category. However this can't help in finding the articles, let alone having an overview of them.

This affects both users and maintainers. An example: Airport data (apt.dat) update. This article is lost in Category:Core development projects and more so in the totally flat Category:Scenery enhancement. The result is that it's totally outdated and also forgotten in the developers portal, for the sure frustration of everyone who cares (like the guy that updated some airports). Most of the pages I randomly visit are tagged as outdated.

I'm not sure if the wiki allows The wiki does not allow searching by more than one category, and that's why categorizing like tagging doesn't work. Yet, I think that a tree structure would fit and help to ease both maintenance and use. A tree structure would force all of the categories to be subcategory of another, and tend to put articles at the leaves.

Note that this doesn't have to be absolute to be helpful. Any article that's in a properly specific, properly deep category will benefit from this.

Why?

Maintainability

This way,every article has its own, well defined place, and it is very easy to find by lurking into the categories. A plus for users and maintainers.

Portals

The category pages have this great gift of being self maintained and can be a perfect reference. The right columns of the Portals need of course some expertise to be maintained, but checking the proper category could help in finding more current articles to add, while removing articles that lose importance. More on Portals below (they're the best thing this wiki has, they're in pretty good shape.)

Reducing duplication

This is the core of the plan. If an article belongs to only one category, you can find siblings that should be merged, or any other instance of duplication; also, you're perfectly certain of what it should talk about, so you would spot sections that should be moved, or articles that should be split.

How?

With tools. Reactivating Extension:CategoryTree is mandatory, but might not be enough.

The ideal tool should allow an organic view of current category tree and do some "drag and drop" and "rename" with categories (and articles) as you would with files and directories. All this as fast (and reversible!) as a "mv" command, to allow for all the experiments that a maintainer could need. Visualizing and trying is a must, be it a model or the real wiki. There will be problematic areas, but fairly limited given the scope of this wiki.

WARNING: I've been warned of possible breakage. Is there any possibility of breaking something by moving/renaming categories and reclassifying articles? (not renaming the latter) I think that could happen only if there are users that use categories to browse the wiki. I highly doubt it, especially for the categories that would undergo the treatment.

The current organization of the portals is an excellent guideline. In Category:Scenery enhancement the subcategories are just ready. Many categories suffer from flatness, probably because of the already mentioned use of categories as tags.

The distribution of this category tree should aim at reducing the time-to-find what you want. Alphabetic order is useless, more so with long lists. At some point, subcategories are the way to go. And once they're present, all articles should go in a proper subcategory. It doesn't matter if a category contains only one article, as far as it has its very own scope, it might find company later. This is because articles should be leaves, not sprouts. Sprouts go unseen.

Isn't one category per article a too strict limitation?

Note: this part might be too thoughtful for what it needs to explain. Please resist.

Yes and no. In fact, some articles might be useful in a couple of related categories. An example is given by Modeling - Getting Started and Howto:Lightmap (as many other modeling/effects/animation related articles). They clearly belong to two macro-categories: Category:Aircraft enhancement and Category:Scenery enhancement. But also to Category:Modeling and Category:Effects (well... pretend it existed).

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 searching by combining categories, we could actually "tag" the articles, assigning one tag per axis, and when browsing there would be means to see directly articles that have these tags combined.

To put it graphically:

* Scenery development                          * Scenery development | Modeling    (and viceversa)
* Aircraft development        Combining        * Aircraft development| Modeling           "
                          X==============>     * Scenery development | Effects            "
* Modeling                                     * Aircraft development| Effects            "
* Effects

Even if this was possible, it might need carefully selected sets of axes and categories.

The alternative 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 above "cartesian product" would do. An example could be the following:

* Scenery development     * ...
                          * Scenery object development     * Object Modeling
                                                           * Object Effects

* Aircraft development    * 3D modeling
                          * 3D model effects

Long story short, what I propose is to replicate this kind of divisions in every macro-category that needs them.

TL;DR.

In conclusion, yes, for some articles that have use in different fields it is appropriate to use more categories. But at two conditions:

• those categories must be strictly comparable in their own areas;
• that article really needs to be valid for both areas.

It's just as having two articles, each at the proper place... only, they're automatically synchronized.

Tree or web?

There is, actually, something I can't make up my mind on: given the above, should also exist the Modeling and Effects categories? It would make it easier for modeling/effects experts to find articles to update, yet they should know well where to find them: being experts they know the lexicon and can make good use of the search function. Would it be worth the hassle of maintaining a web instead of a tree? I can hear my three readers say "yes". Yet there's the risk (risk?!) that a modeling expert adds a new article to one category, but not to the other two. You already have to fix the categories of all the new articles. I say the less crossing categories, the less maintenance work, the better the wiki. I fear it's just not designed for that.

More on Portals

Portals are great, if up to date. As I said, an organized category tree could help a lot in this. The portals are a simplified, friendlier version of the category tree and should be traced over it, up to some appropriate level. Actually, at first they'll guide the rising category tree, but once it's mature it will extend over it. Again, portals are the best thing of this wiki.

I understand that the main part of portals should be used for a basic intro and latest news/announces, so for each of them there should be no more than one "Getting started" article, with a fluent explanation and link to most if not all of the category articles. No more than one, because the intro in the main part will just do the job in most cases.

The right column too should (not shall) follow this idea: linking an article in a portal and its parents is duplication. Gijs makes a good point: some chosen links are indeed a handy exception (confirming that portals maintenance needs expertise.)

One notice on current Portals. The "General" part should disappear: if something is general, either it is introductory (and should be in "Getting started"), or it is too loosely classified.

Remarks on abandoned project articles

Articles related to projects (not only dev projects) should go on their own. They're unmaintainable because authors are the only possible maintainers and they seem to just forget those pages when they abandon or conclude their projects. They could be separated from the most used pages, with a notice to the author for when he/she comes back and restarts, or we might ask before, it's indifferent to me. The point is that there should be an area safe from this mist, on which maintainers could focus their attention. I understand though that there's the risk of duplicating an old project, but keep reading.

An approach to outdated info

I asked on the forum how to update navaids DB. I got no answer, sign that nobody knows or cares about that (or was that the wrong forum?). This means that any effort in updating the navaids DB would mean for the adventurer to do everything from scratch, even if just contacting Robin Peel to verify the only old info available. Basically, he/she could then write an on-purpose article from scratch. So, it makes no sense for old, non-verified stuff to be still around. I basically suggest here to just delete outdated/non-verifiable stuff. If it's outdated, or even if it's not but nobody knows, it's better without: you can't trust it, you can't verify it, and actually nobody seems to have cared since long time but you. It's just frustrating. Moreover, if as a maintainer you stumble on such articles, you might happen not to care either. Then, after asking and finding no answer, safely delete that useless information.

Of course I do understand that it's kind of an heresy here, so this is more of a provocation than a suggestion. Yet having an "outdated stuff" bin where to put such stuff (as for eternally sleeping projects), so that it disappears from up-to-date categories and articles, would be a great relief. Much more than just tagging the article as "maybe outdated", which is pretty much unreliable and useless anyway.

Why outdated is so bad?

I understand I shocked my three readers, so I'll re-eat up all the words I've cut. Let me explain. What's really bad with outdated stuff is that you don't expect it. You click a link and... you're lost. This is really bad to quality perception (you're deluding people). Johan's essay describes this very well, I could empathize that.

Also, by looking at a portal full of links you think "wow, this is full of cool stuff" and don't really get the situation it actually is in. This is an even worse perception problem, because it doesn't stimulate maintenance.

A possible less extreme approach

If I'm an expert of modeling aerobrakes, I'll never look at that article, I don't need it. I'll never know it's outdated, but if I could see its link stand out, maybe with some red symbol next to it, maybe I'd be happy to fix that. Maybe. This sure would help maintainers finding the most outdated areas, but maybe they have other tools.

Rules and guides for contributors

I'm told that most of the days a single person can review all the contributions. So the only rule I'd feel like to suggest would be to prevent articles from being sumbitted without category. However, the less rules there are and the more are respected, so this might be just left out. As Hooray said, a well studied interface could do wonders. Most people will read no rules or guidelines: maintainers will fix that, they know better.

This sounds like the kind of problem that might have already some solution, though.

Let's fix the windows

Another consideration to make is that, as Johan points out in his essay, goodwilled newcomers learn by imitating. Indeed, to categorize my articles I would find a similar, good quality one and use the same category. When articles will have good categorizations, people will imitate good examples. This is kind of the Broken windows theory.

The old site

Have the salvageable material from the old site been moved into the wiki? Would it be technically possible to find and fix all wiki's references to that site?