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

From FlightGear wiki
< User talk:Bigstones
Revision as of 18:40, 7 May 2014 by Johan G (Talk | contribs) (Approaching CategoryTree: Well thought through observations and questions, I will try answer to my best abilities :-)

Jump to: navigation, search

Hi,thanks for taking the time to write down all this. I do agree that improving the wiki structure would be great. Then again, we'll want to do that without introducing any "breakage" - thus, it would be important to do this alongside the existing structure, possibly in some form of "sandbox", with just a few articles (e.g. picking the most popular ones). Also, please keep in mind that the current state of things already represents hundreds of hours contributed by volunteers like you. Roughly 8 years ago it was Gijs who didn't like the wiki structure and then spent dozens of hours coming up with a new scheme, but he made sure not to break anything by implementing his own structure as a suggestion alongside the existing system. That is something that I would also suggest to do here. If you need an extensions to be installed, better discuss this with Gijs first, so that he can review your ideas and then get in touch with Simon (who's maintaining the server).--Hooray (talk) 08:49, 6 May 2014 (UTC)

Hi, I will of course discuss all this with the maintainers (by posting about it on Village pump and Documentation forum). For now this is "private" only because writing it down helped to clarify my mind on some things. I didn't consider possibility of breakage, so that's going to be interesting. I'll soon publish this thing, when ready.--Bigstones (talk) 09:55, 6 May 2014 (UTC)
I made a similar write-up when I had been here for only a short time, Essay:The FlightGear Wiki — Its structure, content and ease of use, though I did it as a subpage to my user page. While you are at it you might want to have a look at the pages listed under User:Johan G#Wiki related subpages. Maybe there is enough ideas around for a wiki quality portal under the wiki portal. ;-)
I think we to some degree have come to similar conclusions, though my focus rather was at having some help for new editors. One thing I spent a lot of time on is documenting the templates (I am still not done). Note that I hardly mentioned categories, they were nearly non-existant (in fact nearly all the images was uncategorised). Unfortunately most editors seem to see them as tags as you have noted, though my biggest grief is when they use a category together with the parent category. I don not believe in strictly one category per page, but if I understood you right, neither do you. What I do believe in though is splitting up too large categories. It is often a lot of work, but needs to be done now and then. As for arranging the categories in a tree structure, I tend to see it like tree with some cobwebs. ;-)
One thing to note about the FlightGear project as a whole is that it is much, much more of a bazaar than a cathedral (if you are familiar with wikipedia:The Cathedral and the Bazaar by Eric S. Raymond. If not it is well worth a read). In essence each contributor tend to do what they care for and find worth while. As for development teams and hierarchy, there pretty much is none. This is probably reflected on the wiki as well for better and worse.
Anyway I am sure we will find more things we agree on (and probably things we disagree on as well).
Johan G (Talk | contribs) 16:37, 6 May 2014 (UTC)
That's a lot to discuss! Just a few quick preliminary comments:
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.
Not sure I understand this. Do you mean that one has to look at the categories at the bottom of an article to see what the article is about? I've never used it that way myself...
giving each article one single category
Why would you want to do that? The definition of a category is that it is a group of several articles that fit a certain subject (or category). A category with just a single article in it means it is redundant and the article should be moved to the parent category.
CategoryTree extension
We used to have this one, but its maintainer had to fix a bug (see FlightGear wiki:Village pump#Found bugs to make it work with the current version of MediaWiki. I just noticed there have been some updates to it lately, so I'll see if I can re-enable it now. (EDIT: re-enabled!)
linking an article in a portal and its parents is duplication.
Often that's true, but there are exceptions. I originally designed the portals to guide people as quickly as possible to the article they're looking for. Portal:Developer for example should only list some of the most used aircraft articles.
Looking forward to the final version of your "review". Always nice to have a fresh impression of our documentation!
Gijs (talk) 19:03, 6 May 2014 (UTC)
I'm really glad and relieved to see these comments, I'd say these ideas are welcome to discussion and that's great. To answer rapidly Gijs:
  • By categories used like tags I mean that instead that using a particular, deep enough category one prefers to use two categories, unrelated, that combine to make a particular one. Details are where I talk about "orthogonal categories" (the too long part).
  • With "one category per article" I mean that each article should belong to only one category. I try my best with english, I'll try to clarify that.
  • I've just read about Extension:CategoryTree in Village pump! I wondered why there wasn't such a useful tool here.
  • OK. If people did like I did with the MCX article, I see why it could have lost quality.
My review is pretty much complete, I see already 3 admins/maintainers (or major contributors?) have read it, how many others do you think will be interested? Do you think it's possible to start a collaborative version of this plan and then condense it in a guideline? That is, avoiding the "wiki quality portal" (cit. Johan).
I'll give a read at Help:Categories and Johan's essay, maybe I can tune my paper towards those to ease discussion (any other document I should consider?). I'll move it to a user page like Johan.
(ps: I've read Raymond's essay a long time ago, much more recently How the FlightGear project works, I'm just fine with that)
--Bigstones (talk) 20:01, 6 May 2014 (UTC)
right, the 3 main wiki admins/maintainers who are currently involved/active have responded here already. As long as you keep your proposals optional, alongside the existing structure, I do not mind you proceeding directly from here, and I am sure that Johan & Gijs are also supportive of your contributions. Just let me say that we do not necessarily need suggestions/proposals or guidelines as much as people willing to actually implement something that works and "release & often", while responding to any community feedback provided. We've seen quite a few people in the last 18 months who expressed an interest in helping with our docs (including the wiki), but I have yet to see anything significant materializing from it, beyond massive discussions, or even fairly critical elaborations about our existing "system" that "just sucks". That is not to say that such criticism would be totally wrong, but we need to come up with something that works for all the parties involved here, especially those volunteering to help with maintaining entities like the wiki or the forum (which is mainly people like Gijs & Johan ATM). Obviously, nothing is "perfect" here, and there's lots of room for improvement - but recently, the FlightGear project seems to attract quite a few people who have a fairly poor signal/noise ratio, in other words if all the time spent debating with others would be spent contributing directly, we'd be in a pretty good shape actually. And even some of the more seasoned contributors seem to be falling victim to this recently, I know it happened to me... Overall, I am in favor of keeping the portal-based system - it's served us well, and hasn't even been adopted completely yet. Regarding more specific feedback, see below:
abandoned project articles
not sure about this one, keep in mind that we have quite a few projects and efforts that had a shelf life of 12-18+ months, I definitely would not delete them unless the author/contributor agrees to do so.
old site/outdated stuff
the website is beyond outside our control, Curt is the one "maintaining" it, and obviously been busy with other stuff - many people have discussed the official website, its design and outdated info, fairly critically - but I'd just suggest to ignore it for the sake of simplicity. Otherwise, Curt would need to provide volunteers with admin/moderator privileges so that they can help maintain it, or move things over to the wiki where we actually have contributors doing exactly that.
rules for contributors
sounds like a good idea, maybe we could have something like the "upload wizard" just for new articles, where the whole thing would be based on a few parameters and customize a few templates, i.e. automatically adding stuff like {{stub}}, {{WIP}} or {{Non-stable}}, based on checking a few check boxes ? Hopefully, there's some kind of extension for "wizard-based" article creation ?--Hooray (talk) 20:24, 6 May 2014 (UTC)
Above comments was moved here from User talk:Bigstones#wiki restructuring. —Johan G (Talk | contribs) 21:37, 6 May 2014 (UTC)

your navdb comments

I never looked at the thread, but I could explain what's involved here - however, it's not exactly straightforward, because our scenery is compiled "offline", and it also uses the same data. There are several dependencies in place here that are not obvious to bystanders. We've had quite a few discussions about doing this sort of thing. So we generally discourage rebuilding your own navdb, unless you know exactly what you're doing (including the TG side of things)-which would mean that you wouldn't be asking the question :-) --Hooray (talk) 07:57, 7 May 2014 (UTC)

I asked that because I've found some hints about "contributing to navaid data", in a "notice to volunteers" in a modeling article (sic) (see here, 3rd red block, then moved here.). I wanted to know if that's actually open to volunteering, like sending Robin new apt.dat's. (I'd actually like to understand what navigation data has to do with scenery. I am curious about that ~100MB file generated any time I add/remove some scenery.) --Bigstones (talk) 20:03, 7 May 2014 (UTC)

Approaching CategoryTree

Thanks for reactivating this great tool. If I'm correct, Category:FlightGear wiki is the root category. I'll make a review and report, can't wait to turn everything upside down!!! In the meantime I will post here any questions that arise, and try to get used to check Special:RecentChanges. I'll also search for the tool I want... but a first try deeply reduced my expectations, I hope in your better confidence with the world of wikis. I hope changing categories hasn't to be done only by manually editing articles.

So. First questions:

  1. Some main categories are there for technical reasons, that is, all of them but Articles and Files, where "real" contents are contained. Right?
  2. Files categories are separated from articles ones. When I upload an image, is the category I choose limited to subs of Category:Files? If not, I'll have to include files in the review of the tree. (in the link above I included only articles).
  3. What do I do with non-English articles? In most cases I can figure out what they talk about. Are categories universal with respect to this or non-English articles are sort of an independent wiki?
  4. Inside Category:Articles, I'm not sure I understand the Documentation cat. What isn't documentation in a wiki? Aren't aviation articles documentation as well? (this question should go in the review actually)
  5. Any major changes will only be planned and go in the review. But meanwhile, can I safely do the following?
    1. Remove articles from parent categories, if they're already in subcategories
    2. Move articles to existing subcategories
    3. Create subcategories where to move clearly too generally categorized articles
(note that the above will begin to shape a tree with leaves, but won't break the "web" structure, that is, I won't follow "one article, one category" yet. Actually, I expect the above to be common maintenance)

--Bigstones (talk) 21:06, 7 May 2014 (UTC)

1. Yes, though one other thought I had when creating Category:FlightGear wiki was to also have it serve as the root for the pages in the various namespaces (i.e. Main/Articles, File, Help, Portal, Template and User), though I chose to put both of the articles in the "FlightGear wiki" namespace in that category as well. In other words I intended to have in it the root categories for pages in each namespace as well as Category:Hidden categories and Category:Wiki maintenance that did not really fit well anywhere else.
I should also mention that I created that category because there seemed to be a few separate trees that did not connect at the roots while I was hunting down all but one of the uncategorised categories (I seem to be unable to edit the only page linking to the last one, Template:Ru/Черновик).
2. You can chose any category when uploading files. In the last months/years a lot of files have been added to article categories. While that could work I feel that it would be messy and make it harder to find the right image when browsing for images specifically. Personally I would prefer if a file category was added to a article category instead of all it's images. In some cases that would work splendidly in other cases not. For example Category:Screenshots fits well under Category:Software, but i do not think that Category:Icons would fit well under any article category.
When it comes to newly uploaded aircraft images I feel in part that I am at fault. When I categorised the the bigger part of the existing ones (hundreds of them, and still not done) I unfortunately did not think the category structure and naming through properly, so those ended up in a few large heaps of screenshots, the worst one probably being Category:FlightGear exterior screenshots‎ (nearly 500 images). I also showed poor judgment in category names. I could have skipped FlightGear in the category names (talk about being implied ;-). Had they instead been for example "Aircraft interior screenshots" they would also probably be easier to find in the upload wizard. Though all this is easy to say now afterwards...
3. My tip in regards to the non-English articles is to use the language links and use the categories of the corresponding English article. Currently the non-English articles are the ones remaining to be categorised (except for new and a few old ones), I have kind of saved them for last and focused on the easy ones.
4. I think I created Category:Documentation to bind together Category:Howto and Category:Core developer documentation. I guess it just went on from there with not too much thought into it mainly aiming at connecting related categories and articles, again probably when hunting down uncategorised categories.
5.1, 2 and 3 Definitively! I would be doing it myself if it wasn't such a chore, lol. And yes indeed it is common maintenance.  :-) When creating new category names, it is well worth the time to come up with meaningful category names, which as I mentioned above, is sometimes easier to see in the rear-view mirror... ;-)
Johan G (Talk | contribs) 22:40, 7 May 2014 (UTC)