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

From FlightGear wiki
< User talk:Bigstones
Revision as of 14:02, 8 May 2014 by Johan G (talk | contribs) (→‎Approaching CategoryTree: Trying to rephrase my answer to the first question, while trying to stick to the subject)
Jump to navigation Jump to 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)
contributing to new/improved navaid data is indeed appreciated, but different from actually using it in FlightGear. To better understand the motivation behind asking people for navdb updates (R.Peel), you need to understand that the original data source (DAFIFT) has been discontinued, so that the corresponding data is no longer freely available to projects like FG/XP etc. According to R.Peel's website, they're currently planning to come up with a web-based interface that would allow people to contribute directly in some kind of wiki-like fashion, which is something that we've been discussing on our forums for years. We have some contributors who worked on similar tools, so it would make sense to coordinate things a little-but otherwise, contributing improved data doesn't necessarily mean that you'll be able to directly use it in FG. The ~200MB file you are referring to is a SQLite database created from those plain text files, so that we can better support geospatial queries (=more efficient spatial searches). In addition, it's intended to reduce the startup/initialization overhead, by building the DB once and then using the pre-created cache subsequently. In theory the feature itself is great, but it has caused quite a bit of headache over the years, because there are numerous issues that only show up for some people, such as the process taking hours to re-build the cache, weird localization issues and other performance issues.--Hooray (talk) 09:00, 8 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)
I forgot to mention it above, but one of the technical limitations of the MediaWiki wiki software is that one indeed have to edit each categorised page to change its category since they are categorised by the use of the category links. Thankfully if all the pages in a category should need changing the category, in essence "moving" the category from one name to another it can be done with a so called "bot job".
About those FlightGear screenshot subcategories: I have thought about to at some (undefined) point in the future request Gijs to set up a bot job to change those names into more meaningful ones.
Johan G (Talk | contribs) 22:57, 7 May 2014 (UTC)
1. is not very clear to me.
2. I agree with you. Maybe something can be done to force the interface to use only Files subcats, and a bot can move the "leaked" files. Writing a bot is not the first of my dreams, though.
3. They're a bit noisy actually. But maybe that job can be automated too.
4. Well, as grandparent categories should have not many subcats, it can be changed any time.
5. Great! (I wonder why in so many years of existence of mediawiki, nobody ever created a drag'n'drop interface for such stuff.)
--Bigstones (talk) 23:08, 7 May 2014 (UTC)
About your reply to my answer to the first question. Is it the namespaces that are confusing or was I a bit confusing? Maybe I should rephrase myself, I tend to both be rather verbose and to stray from the subject. ;-)
To sum it up as short as possible I created it as the root category, since I found that there wasn't one when I categorised uncategorised categories.
The different namespaces (speaking of namespaces in general, not the categories) contain wiki pages that are used in different ways. For example category links will show up as categories at the bottom of pages, templates does not need the "Template:" prefix when included into a page using curly braces, only pages in the main namespace show up in simple searches etc. That, and that the English Wikipedia have a root category in a similar fashion[1] is the reason why I have created root categories for the pages in each namespace. That said the root category was not meant to be reserved only for "namespace categories" though I feel they fit nicely in it.
Did that help?
Johan G (Talk | contribs) 14:02, 8 May 2014 (UTC)

Tools for a better "new article" interface

I was looking for the supertool (it seems what I want is a bot, however a lot can be done without, so it'll wait), while I saw these and thought they could be useful for a better "new article" interface:

--Bigstones (talk) 22:44, 7 May 2014 (UTC)