User:Bigstones: Difference between revisions

Jump to navigation Jump to search

User:Bigstones (view source)

Revision as of 20:09, 6 May 2014

14,862 bytes removed ,  6 May 2014
moved the reorganization plan
(i think it needs some synthesis)
(moved the reorganization plan)
Line 1: Line 1:
Working on [[LIPY]] scenery, randomly maintaining the wiki.
Working on [[LIPY]] scenery, randomly maintaining the wiki.


----
Writing [[User:Bigstones/Essay:A plan for a reorganization of the wiki|A plan for a reorganization of the wiki]]


{{WIP}}
[[Category:Users]]
== A plan for a reorganization of the wiki ==
 
=== Introduction ===
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, probably in other areas too, and I'm sure I'm not alone. I don't know why it's not happening, so please let me know if there's a good reason. I hope my organizational skills and experiences will be useful (as much as my volunteering), and here are my ideas on this. 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.
 
:''Please forgive me if it seems impertinent or even arrogant, as a newcomer not even expert with wikis, to land here and give hints to people that have been working on the documentation since the beginning. It is not my intention and I do hope these ideas will just be useful. Also, I might point out problems that are only mine, or just a misunderstanding of the current organization, or that just aren't there. I might have been so unlucky to stumble on all the defects of this wiki! I choose to put aside any diplomacy, only for brevity and clarity. Forgive me again.''
 
:''Oh, let's be onest, I don't want to help. I just want to use this wiki and work on it without teeth grinding and cheek biting. (lol)''
 
=== Restructuring the categories into a tree ===
I see that categories are used as tags, that is, they're combined so that by looking at an article categories one has an idea of what it talks about. However this is not helping in finding the articles, let alone having an overview of them. This affects both users and maintainers.
 
In fact, see this: [[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 recently updated some airports). Most of the pages I randomly visit are tagged as outdated.
 
<s>I'm not sure if the wiki allows</s> ''The wiki does not allow searching by more than one category,<ref>Hey, looks like it's [https://en.wikipedia.org/wiki/Wikipedia:Category_intersection a major issue of MediaWiki].</ref> 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.
 
==== Why? ====
;Maintainability: This way, you know for sure what category an article belongs to and what it should talk about, 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.
 
;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 choose the articles to put there, but nobody is fully expert. By checking the proper category, the maintainer would be allowed to see if there are articles that might be important and that he/she didn't know about, and possibly add them (there shouldn't be dozens of them or that list becomes pointless).<ref>I made these considerations while linking my [[Howto:Convert objects with ModelConverterX|MCX howto]] to the portals: why my lousy article is here, and not other of higher importance??</ref> More on Portals below (they're the best thing this wiki has, they're in pretty good shape.)
 
;Reducing duplication: But most importantly, 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, sections to be moved and any other instance of duplicated information. Fixing this will be a major help in making the wiki more maintainable.
 
==== How? ====
Well, to do all this, there sure is need of tools. So far, the only one I've found that could be useful is [https://www.mediawiki.org/wiki/Extension:CategoryTree Extension:CategoryTree].
 
In general, these tools 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. 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, and if the tools work fast it won't take long. There ''will'' be problematic areas, but fairly limited given the scope of this wiki. 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)<ref>If possible, I'd love to experiment this on a public copy of the wiki. Is it possible?</ref>
 
The main categories are actually already there. The current organization of the portals is an excellent guideline. I was recently pointed to [[:Category:Scenery enhancement]] where the subcategories are just ready, only they're noted down and not yet applied.<ref>That's called doing the right thing with the wrong tools.</ref> 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.
 
The distribution of this category tree should consider mainly one fact: alphabetic order of articles that begin with "make" or "add" is pretty much useless, more so if there are more than a dozen of them. So, whenever a category reaches such an (arguable) size that you can't find what you want with little more than a glance, subcategories is the way to go. And once they're present, articles with a too general category should be moved into more particular ones. It doesn't matter if a category contains only one article, as far as it has its very own scope. Articles should be leaves, not sprouts.<ref>Sprouts go unseen, and this kind of sprouts will probably rotten, not grow.</ref>
 
==== Isn't one category per article a too strict limitation? ====
''Note: this part might be too thoughtful for what it needs to explain. You can skip to'' TL;DR.
 
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 much as most of the modeling/effects/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 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, one tag per axis, and there would be means, when browsing categories, to see directly articles that have these tags combined.<ref>Another axis that comes to my mind is the one that distinguishes normal articles from howto's. I think that it's a category that only complicates things, using the namespace would be enough and sounds more appropriate because it's a distinction not on contents, but on the style of the article. As a user, I don't care if an article is an howto, as long as it tells me what I want.</ref>
 
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        Combining        * Aircraft development| Modeling          "
                          ==============>    * Scenery development | Effects            "
* Modeling                                    * Aircraft development| Effects            "
* Effects
</pre>
 
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:<ref>I changed categories again, 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
                          * 3D model effects
</pre>
 
Long story short, what I propose is to replicate this kind of divisions in every macro-category that needs them. Which one of the "axes" should become the macro-categories is technically a detail, but the current organization and the fact that a user will probably be focused in modeling planes ''or'' scenery, pretty much answers the question.
 
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:<ref>There actually is something I can't make up my mind on: given this, 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.</ref>
* ''those categories must be strictly comparable'';
* ''that article really needs to be valid for both areas''.
 
It would be like having two articles, each at the proper place... only they're automatically synchronized.
 
A note on the second point. There might be articles that seem written just for aircraft/scenery modeling, but that actually are fine for the other too. In general one should aim at not splitting such articles and making them more generic, so that the same kind of knowledge stays at the same place. This way, when some new technique is available, you don't have to update two articles (with all the risk of forgetting one).
 
=== More on Portals ===
Portals are great, if up to date. As I said, the category tree could help a lot in this. The portals should be a simplified,  friendlier version of the category tree and traced over this, up to some appropriate level. I understand that the main part of portals should be used for a basic intro and latest news/announces, <ref>The last ones might need some maintenance in [[Portal:Developer]].</ref> so for ''each of them'' there should be ''one'' accessory article, that gives a better general explanation (is it actually needed? you know nobody will maintain it) and link to most if not all of the category articles in a conversational way. This is of course the "Getting started" article.<ref>For the articles left out, one should check that they're properly reachable from the articles included.</ref> Such articles won't be needed for non-edge portals, of course because articles should be leaves, and the more generic portals should not have any. The right column too should follow this idea: linking an article in a portal and its parents is duplication.
 
One notice on current Portals. The "General" part should disappear: if something is general, either it is introductory (and should go in "Getting started", which actually should be one article we said), or it is unclassified and needs to be classified.
 
=== Remarks on abandoned project articles ===
Articles related to development projects should go on their own. They're unmaintainable because developers are the only possible maintainers and they seem to just forget those pages when they abandon or conclude their projects. I don't know if these scarcely maintained pages should be just deleted (I probably would) but they sure should be separated from the most used pages, to avoid confusion. There should be an area safe from this, on which maintainers could focus their attention.
 
=== The old site, and an approach to outdated info ===
I was looking for information on contributing to the navaids database. I landed on the [[Frequently asked questions#How current is the data in FlightGear compared to the real world?|faq article]] where I was linked to a 13 years old web page (and counting) which talks about win 95/98 and 2000. I know that it's a very old project where some stuff is still valid, I might also have been very unlucky, but I was astonished.<ref>Hey, I couldn't drive cars when that was written. It's a damn long time!</ref> I guess it's time to also review the old site and move the salvageable stuff into the wiki if not already done - and possibly remove any reference to it. Would it be technically possible to find all such references?
 
By the way, [http://forum.flightgear.org/viewtopic.php?p=208268#p208268 the same question on the forum] went unanswered, 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 what that old document said. Basically, he/she could write an on-purpose article from scratch. So, it makes no sense for old/unverified stuff to be still around. I basically suggest here to just delete outdated stuff. If it's outdated, or even if it's not but nobody knows, it's the same as if it's not there: 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 confusing. 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, 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 for anyone.
 
=== Rules 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.
 
=== Notes ===
<references/>
Bigstones
573

edits

Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/70633"

Navigation menu