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

From FlightGear wiki
Jump to navigation Jump to search

A plan for a reorganization of the wiki

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)
Definitely, thanks. --Bigstones (talk) 14:18, 8 May 2014 (UTC)

Development classification

Ok. Now I have another couple questions:

  • What's the reasoning behind the distinction between Category:Developer Plans and Category:Development projects? Does it make sense to tie development plans to a developer? Or is there a difference between plans and projects? (ok, the former are just dreams, but the latter don't guarantee anything.)
  • What exactly makes development core?
    1. Changing C++ in fg/flightgear Git repo
    2. Changing C++ in any fg/ Git repo project
    3. Coding in C++
    4. Any coding related activity (i.e. including nasal and python) integrated in fg
    5. Like above but also separate tools like osm2city
    6. Anything but aircraft/scenery development (excluding also little nasal scripts for animation purpose)
  • Is shader development core? is it sorcery?

--Bigstones (talk) 22:48, 8 May 2014 (UTC)

* Developer plans are plans by individual developers, i.e. collections of ideas and publicly stated goals, without anybody actually working on stuff necessarily, i.e. long-term stuff that people are interested in.
* development projects are projects that people are actually working on
* yeah, it very much makes sense to associate developers with plans, because there are more ideas and feature requests than be handled realistically. But whenever an idea or "plan" is associated with a known contributor, that idea/plan has obviously more weight than some random suggestion coming from someone external to the project. And certain plans have even much more weight than others, e.g. Plan-zakalawe or User:TheTom are fairly representative simply because those are the two main guys handling the majority of commits for the time being[2]. Having people linked to ideas/plans is a good thing in my opinion, because we -as contributors- can actually learn who supports certain ideas. For instance, whenever I support a certain idea, I am willing to provide mentoring, and I know of others like Philosopher, who also provide additional support for certain projects.
* core development is C++ development, usually handled by core developers, i.e. people with commit access - or at least C++ development by people who are working towards getting this committed, i.e. not some branch that is intended to be never merged, aka irrelevant to the main project (fork).
* scripting in Nasal/Python is generally not considered core development, unless it touches core development stuff - e.g. in the case of Canvas which makes certain C++ code obsolete through scripting space bindings.
* osm2city et al are not considered core development, but the people working on those features are hoping to eventually re-implement some parts via core extensions.
* shaders are middleware/base package development, i.e. do not typically require SG/FG commit access or C++ changes, and are thus not generally considered "core" development.
* Overall, I'd suggest not to tamper with categories/areas that you don't understand, i.e. that require interpretations of different types of contributions-those categories are unlikely to be relevant to end-users anyway. And people who are looking for this info will typically also understand the various differences. Cleaning up such things is low priority in my opinion, someone able to build from source and program in C++ is unlikely to be affected by proper/improper categories, so no need to waste any time here-better focus on popular articles and categories first. Existing contributors, especially core developers, are unlikely to benefit greatly from such wiki improvements, and to be honest: most of us don't care at all - there are very few core developers who actually contribute to the wiki, let alone care for formalizing such differences and boundaries.--Hooray (talk) 23:16, 8 May 2014 (UTC)
Thanks for spending the time, I fully understood the Developer Plans part and the last part is practically the "safe area" I wrote about (kinda scared by the amount of data you harvest and pile up everyday). However, if this is how things are, maybe that could be renamed to Core developer plans. It might be a minor change, but clarifies the boundary, or that might get filled by random plans (I myself put some stuff there and will remedy). I didn't expect core devs to be so few. PS: Sorry for the "NOPE not c++" commit, I should have read a couple lines more!
--Bigstones (talk) 23:59, 8 May 2014 (UTC)
no problem (galvedro's work may actually be overlapping with C++/core stuff soon), I just wouldn't prioritize stuff that's really only of interest to people who are either already contributors or who're interested in becoming core developers, that's kinda a niche and once someone is at that stage, they're not going to be bothered by certain inaccuracies or confusing wiki categories.
Maybe better coordinate such things with Gijs and Johan_G to find a more self-contained area that benefits from your additions ? Being "all over the place" could be potentially problematic as long as there are concepts and connections that still need to be understood.
I am just saying this because we're obviously grateful for anybody volunteering here, especially people willing to do "chores" that really only 2-3 guys are doing otherwise (actually, I don't typically help with such things at all, so it's really just Gijs & Johan).
Developer plans vs. core developer plans - we do have developers/contributors who have plans outside core development (e.g. Nasal), so that's where that distinction came from. Then again, nothing is set in stone - it should just be kinda plausible to most people. There's nothing wrong about "random plans" as long as there's a contributor (not just end-user) that can be associated with such ideas, either willing to work on them, or at least support/mentor people.
Otherwise, we'll just end up with tons of unsupported ideas & plans. As I said, it makes a huge difference for us as a project and community of contributors, being self-organized, just who exactly supports certain ideas - this applies certainly to anything that is not just a trivial weekend hack, but requires many weekends of spare time coding.
For example: This is kinda how Gijs' NavDisplay project took shape (no core development either): Zakalawe was supportive of it (it aligning well with his own plans to get rid of certain C++ code and unify/modernize our OpenGL code via Canvas), so that others (Hyde, Philosopher, I) knew that this would be a worthwhile project because we had "community/contributor" support (not just through ideas, but helping hands). And others like TheTom also knew that there were a handful of contributors involved, so our RoR is much greater because contributions are magnified by others working on similar problems. Yet, we had to identify overlapping areas and decide what we wanted to work on - splitting up the whole thing into components, so that the MapStructure folks will normally not have to touch the NavDisplay stuff (and vice versa). Likewise, there are similar projects, like a Nasal/Canvas animation framework or a PFD framework that simply have certain community support, i.e. in the form of people willing to provide help/support.
So we are using "contributor momentum" to evaluate popularity of ideas and to determine if we're interested in teaming up with others who have similar/overlapping ideas. Having just a huge collection of "random & unsupported" feature requests or ideas is begging for trouble, and is the main reason why the issue tracker is not intended for feature requests, i.e. to remain useful for people who are actually able to do certain work. Which is where the wiki shines: Ideas/plans gathered here by contributors (instead of end-users) obviously matter more, even if they should never be touched in months[3], they're representing long-term direction. And obviously it also matter just how active a contributor is at any given time, ideas and plans have more weight if someone is still involved and very active, vs. others who are no longer involved or very inactive. We have some fairly active fgdata developers whose contributions are not quite in line with ideas laid out by core developers who are meanwhile pretty much inactive, obviously activity beats inactivity. --Hooray (talk) 07:35, 9 May 2014 (UTC)

Article versioning

I'm all over the place *to* understand concepts and connections. I do that because I still believe that there should be a better separation between stable documentation and projects documentation, for the good of normal users, not core devs! While learning scenery development it was a major annoyance stumbling in old surpassed project pages, and I kept having the feeling that I didn't know everything I should. I didn't trust much the portals, either. The forum was a great support in this and it's wonderful that nobody ever answers "use the search" (which is the standard in Italian forums). Nevertheless, no surprise people say the wiki "just sucks". It took me some time to decide to join and I was not far from staying away.
--Bigstones (talk) 14:07, 9 May 2014 (UTC)
Having better separation between stable/development articles/docs would be great in my opinion, too. We've been discussing this for years actually. I am still in favor of supporting branching/forking articles, along with tagging for each version. Currently, it's too late - but it's certainly worthwhile to discuss and consider beginning with 4.0. So far, I am dealing with this by using lots of notes and adding version specific stuff to the template. But I am convinced that we should follow wikipedia here, i.e. introduce the notion of article tagging, and requiring stable articles to be reviewed before being published, see for example:
the main point being here that you don't need to read through dozens of postings/pages (BTW: Yes, that could also mean USE THE SEARCH!), but that discussions are generally not as useful as establishing mechanisms and infrastructure and "enforcing" things - the FG community is generally pretty clever, but we're extremely unorganized and even chaotic at times, we've had countless good discussions and proposals to fix some very long-standing FG issues (including quality of wiki docs), but usually that's the only thing that really materializes unfortunately: talking, and very clever suggestions that end up forgotten in the archives. Now, with regard to wiki tagging and stable/unstable (versioned) docs, I am fully supportive of it and willing to help get this going. And both, Gijs & Johan_G have commented on the issue too - it just needs to start somewhere. I would suggest to prepare this for 4.0, draw a line, and begin splitting things accordingly. Obviously, it would be up to other volunteers to help with older releases, but I am only interested in doing this for 3.2, or better, 4.0. Even if this is something that neither of us is going to tackle anytime soon, this would warrant having a dedicated article about the whole idea, because people keep reinventing the same solutions... --Hooray (talk) 15:39, 9 May 2014 (UTC)

Tools for a better "new article" interface

I was looking for the supertool, while I saw these and thought they could be useful for a better "new article" interface:

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

I would agree that having some kind of article creation wizard would be kinda useful. I am still looking for a good way to unify handling for identical contents, i.e. changelog/newsletter and development announcements.--Hooray (talk) 15:15, 8 May 2014 (UTC)
An alternative to an article creation wizard could be to pre-load a skeleton page (i.e. not a wiki template), but I do not think that would help finding a category all too much. Personally I would prefer to have neither, but perhaps there could be a link somewhere suitable to help interested users create a page using a skeleton page?
—Johan G (Talk | contribs) 19:16, 8 May 2014 (UTC)
The file upload wizard seems to work pretty well, and a category (existing or new) could be made mandatory. There's several extensions that we could try, e.g. see: https://en.wikipedia.org/wiki/Wikipedia:Article_wizard --Hooray (talk) 19:28, 8 May 2014 (UTC)

Bot proposal (request?)

Talking about supertools, it seems what I want is a bot.--Bigstones (talk) 22:44, 7 May 2014 (UTC)

I think bots can currently only be run by Gijs (well, obviously also Simon as the wiki admin). Given the potential damage that may result from running a bot script, I would always ask others to review/test the bot first, and maybe run it in some kind of sandbox or sub-portal. Gijs once explained the requirements for running scripted bots to me, but I haven't yet had a real need for doing so, and I don't think "normal" wiki admins have the necessary permissions. But if there's anything that would be lots of work to do manually, I can help with coming up with a python bot/script to automate that (of course, we'd first of all need to agree that we want to proceed accordingly)--Hooray (talk) 15:15, 8 May 2014 (UTC) (moved by --Bigstones (talk) 20:14, 8 May 2014 (UTC))
There is actually something easy that a bot could do right now, in fact I was just reading on bots and found a java framework (I don't know python), although not looking forward for that... so I really appreciate your offer. I'm talking about point 5.1 in the above #Approaching CategoryTree, I quote them:
  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
There are many that suffer from that, and as that's an automatable task, it'd be better done automatically before the other two (non automatable) tasks, because those articles would get in the way and I would end up doing that work manually. E.g.: Requesting Technical Help belongs to Category:Documentation and Category:FlightGear. The second one is already into Documentation, so this one should be removed. It should be easy to open every article and cross check their categories. The hardest thing to do is probably preload and cache the category tree for faster lookup (if possible).
--Bigstones (talk) 17:59, 8 May 2014 (UTC)
Alternative to a bot for many tasks: Extension:Replace Text
--Bigstones (talk) 10:54, 9 May 2014 (UTC)
Retrieved from "https://wiki.flightgear.org/w/index.php?title=User_talk:Bigstones/Essay:A_plan_for_a_reorganization_of_the_wiki&oldid=70782"