Hi fellow wiki editors!

To help newly registered users get more familiar with the wiki (and maybe older users too) there is now a {{Welcome to the wiki}} template. Have a look at it and feel free to add it to new users discussion pages (and perhaps your own).

I have tried to keep the template short, but meaningful. /Johan G

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

From FlightGear wiki
< User talk:Bigstones
Revision as of 17:08, 7 May 2014 by Bigstones (Talk | contribs) (Approaching CategoryTree: fixed a potentially catastrophic statement)

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)
Hi,
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)