User:Bigstones: Difference between revisions

:''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 choose to put aside any diplomacy, only for brevity. Forgive me again.''

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 an article categories one has an idea of what it talks about.

<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 it's [https://en.wikipedia.org/wiki/Wikipedia:Category_intersection a major issue of MediaWiki].</ref> and that's why categorizing like taggging 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.

;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.

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. There ''will'' be problematic areas, but fairly limited. I've been warned of possible breakage. Is there any possibility of breaking something by moving/renaming categories and reclassifying articles? (not renaming them)

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 a size such 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 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>

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 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).

To put it graphically:<ref>I renamed the categories: why enhancement if most articles talk about creation? However names is a minor issue.</ref>

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> An example could be the following: