573
edits
User:Bigstones: Difference between revisions
Jump to navigation
Jump to search
that's pretty much it. needs a bit of review and it's ready.
(that's pretty much it. needs a bit of review and it's ready.) |
|||
| Line 7: | Line 7: | ||
=== Introduction === | === 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 | 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 or it's just lack of volunteer time. | ||
I hope my organizational skills and experiences will be useful (as much as my volunteering), and here's my ideas on this. | |||
:'' | :''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.'' | ||
:''(I also didn't search too hard for any similar plans, but I don't think there are | :''Also, I might point out problems that are only mine, or just a misunderstanding of the current organization. I choose to put aside any diplomacy, only for brevity. Forgive me again.'' | ||
:''(I also didn't search too hard for any similar plans, but I don't think there are.)'' | |||
=== Restructuring the categories into a tree === | === Restructuring the categories into a tree === | ||
I know some Java programming and I'm used at the fact that a class can extend ''only one'' other class<ref>This is not the case in other languages like C++.</ref>, thus you clearly know what kind an object belongs to; this is not happening in the wiki: I see that | I know some Java programming and I'm used at the fact that a class can extend ''only one'' other class<ref>This is not the case in other languages like C++.</ref>, thus you clearly know what kind an object belongs to; this is not happening in the wiki: I see that categories are used as tags, that is, they're combined so that by looking at them 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. In fact, see this: [[Airport data (apt.dat) update]]. This article | 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 frustration of everyone who cares. | ||
I'm not sure if the wiki allows | <s>I'm not sure if the wiki allows</s> The wiki does not allow searching by more than one categorizations,<ref>Please keep reading and you'll see what I mean. BTW, looks like I've found [https://en.wikipedia.org/wiki/Wikipedia:Category_intersection a major issue of MediaWiki].</ref> and that's why categorizing like tags 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 (most?) of the categories to be a subcategory of another. | ||
==== Why? ==== | ==== Why? ==== | ||
;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. | ;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 nevertheless outdated information, which leads to confusion and frustration and grinding teeth... we've all been there, I'm sure. | ||
;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. | ;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, however, the maintainer can 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 dozen 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. | ||
;Early benefits: But | ;Early benefits: 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, and any other instance of duplicated information. Fixing this will be a major help in making the wiki more maintainable. | ||
==== How? ==== | ==== 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. | 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. | 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. There ''will'' be problematic areas, but fairly limited. | ||
The main categories are already there. The current organization of the portals is an excellent guideline. I | The main categories are 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 done "by hand" 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 a size such that you can't find what you want with a glance, subcategories is the way to go, and once they're present, articles with a too general category should be moved in the more particular ones. 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? ==== | ==== Isn't one category per article a too strict limitation? ==== | ||
''Note: this part might be too thoughtful for what it needs to explain.'' | ''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 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 | 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 much 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 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 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. | 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. | ||
| Line 65: | Line 69: | ||
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 given the current organization and the fact that a user will probably be focused in modeling planes ''or'' scenery, pretty much answers the question. | 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 given 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: | In conclusion, ''yes, for some articles that have use in different fields it is appropriate to use more categories''. But at two conditions: | ||
| Line 70: | Line 76: | ||
* ''that article really needs to be valid for both areas''. | * ''that article really needs to be valid for both areas''. | ||
A note on the second point. I've seen articles that seem written just for aircraft/scenery modeling, but that actually are fine for the other too. In general one should aim not to split such articles, so that the same kind of knowledge stays at the same place, | A note on the second point. I've seen articles that seem written just for aircraft/scenery modeling, but that actually are fine for the other too. In general one should aim not to split such articles and make 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 (and be sure they'd get out of sync). | ||
=== More on Portals === | |||
Portals are great. If up to date. And coherent. As I said, the category tree could help a lot in this. The portals should be a simplified, accessible and friendlier version of the category tree. I understand that the main part of portals should be used for a basic intro and publish latest news/announces, <ref>The last ones might need some maintenance in [[Portal:Developer]].</ref> so for ''each of them'' there should be ''one'' introductory article, that gives a better general explanation (is it actually needed? you know nobody will maintain it) and link to | |||
One notice on Portals. The "General" part should tend to disappear: f 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 development articles === | === Remarks on development/projects articles and "others" === | ||
those should go on their own, they're unmaintainable. most of these pages are doomed. developers are the only possible maintainers and they seem to just forget them when they abandon or conclude their projects. SAFE AREA: There should be an area safe from this. "Others" are articles not foreseen by this text. | |||
=== The old site === | |||
I went in the faq article and i was linked to a web page which talks about win 95/98 and 2000. I mean, come on | |||
=== Notes === | === Notes === | ||
<references/> | <references/> | ||