Hi Bryce,
as you seem to have made up your mind about shutting down the MediaWiki despite peoples concerns (which I still don't think is a good idea to start with for the reasons explained before) let's start from there...
I'm sorry to sound negative here but with the current plan I see a *lot* of work heading our way that will not result in any improvement over our current infrastructure at all. At the very best (if - and only if - we have the manpower to get this done properly) it might become equivalent. As the past has shown the spare time to fiddle with documentation is a *very* rare good and in my humble opinion we should abstain from spending it all on administrative tasks like splitting, moving, copyediting, whatever.
Now to poke some holes:
#1 - Application documentation and reference source files are moved to Inkscape's share directory in VCS. Extension references, output format details, tutorials, usage advice, and so on. This will be shipped with the application, and probably worth rendering in some web-viewable format as well. Nearly all of this will be worth translating.
I honestly have no idea what exactly you have in mind here. For "extension reference" do you mean "user documentation for existing extensions" (we have [1] but this is nothing that is ready for a wider audience, let alone translation) or "developer documentation on how to write extensions" (then I don't think it fits the category). Tutorials are already in share and all the rest sounds very vague.
[1] http://wiki.inkscape.org/wiki/index.php/Extension_reference
#2 - Strictly user-facing pages in the wiki are moved to the main website. High level project info, roadmaps, user-oriented FAQs, community resources, and so on. If a page requires advanced styling or layout functionality in our current mediawiki, that would be a strong indication it should be moved to our Django. This will obviously take time and effort but can be tackled bit by bit. Most of this is worth translating.
Finalized release notes will become part of the releases app; this will support html and translations.
This is one point I fully agree with you, but as brynn noted with the exception of release notes this is pretty much the current state.
#3 - Static coder-facing documentation should be moved to Inkscape's doc/ directory. This includes anything that documents implemented designs, protocols, and other assorted functionality. It also includes coder tutorials and guidelines. Generally materials that can be considered "finished" and worth keeping for reference value. This doesn't include unimplemented ideas/proposals, nor anything that is obsolete or that we're keeping simply for historical purposes. Little of this will be worth translating.
When is coder-facing documentation ever "static"? The current reality looks more like: developer A adds a feature, developer B sees the need to document it some and adds a very short notice in the Wiki, developer C wants to use the feature and is struggling with the rare information and then hopefully adds enough information to be useful, developer D finds it and is finally able to work with it and fixes the remaining inaccuracies, typos and grammatical errors; only then it starts to become useful, but at that time a code change probably made it outdated or even obsolete. The thing that probably comes closest to what I understand you have in mind is [2] (including subpages). Does that mean we remove that information from the website (I don't think so)? Does that mean we duplicate that content (We partially have that in the Wiki and it's problematic at best as it effectively doubles the maintenance work and is likely to have one of the copies outdated)?
[2] https://inkscape.org/en/develop/
#4 - Dynamic development pages are moved to the git*b wiki. This includes design mockups, development plans, todo lists, architectural brainstorming, infrastructure refactoring proposals and the like. A lot of the stuff currently registered as blueprints, that are adequately well fleshed out and that may be worth including in our official roadmap, should also move here. None of this should be translated.
The release notes under development for the trunk codebase are drafted here in this wiki. Perhaps eventually we'll move editing to the releases app. This also includes organizational documentation for the Inkscape board, pages relating to fundraising, hackfest planning, and so on.
Again, what are "dynamic" development pages. As noted before I'd consider basically everything developer-related dynamic and I could live with having that all in a git*b wiki (do we really still call it git*b? For that decision it seems some people have already made up their mind, too). If you ask me that is actually the way I'd prefer and the only reasonable solution: Everything developer-related goes into a gitlab wiki where everyone is welcome (and encouraged!) to improve content. An arbitrary splitting of developer-documentation will only result in duplication (with your suggestion we'd have Website, VCS, developer Wiki, maybe even some pages in the community Wiki you mention below. That's three locations to many!).
#5 - Obsolete pages are left in the current wiki, but "mothballed" for historical reference.
If we want to draw the line and shut down the MediaWiki do it correctly! The old content should not be easily accessible. If there is important content it *has* to be moved so that basically nobody will ever have a reason to look at the old Wiki again. If we can't manage that then we should not attempt the move at all (hence my initial doubts!). The worst case scenario I see is that Google indexes the old Wiki and people continue to work with that information while the new information is hidden somewhere deep in the VCS or gitlab.
#6 - A "Community Wiki" will be established with open access for members of the wider Inkscape community, to use as a freeform collaborative editing space. There would not be rules about what can and can't go in here, but this is where folks would go to do collaborative brainstorming, flesh out raw ideas, and share random wishes and bits of information not ready or suitable for inclusion in any of the above. It should be easy to register for and easy to edit, but also robust against spam. All other pages not covered by 2-5 above, will end up here.
As a general rule of thumb, if a page in the Community Wiki is important enough to be worth translating, or if we find ourselves linking to the page frequently, then that is a sign the page ought to be promoted and moved elsewhere. This could be an updated MediaWiki like we currently have, however I'd like to see thought given to alternative solutions, such as a Django wiki plugin that allows tighter integration with the website, or even using an externally maintained wiki service. It could also be a special Git*b project with really lax rules for committing. Whatever we pick, the important things are that it's widely available to all, easy to use, and very light on rules or imposed structure.
No! Thinking about yet another Wiki is just stupid (sorry). Where do we save *any* resources by decommissioning the old MediaWiki only to create another (potentially Media-)Wiki, a gitlab developer Wiki and even more documentation in VCS? In my opinion the Wiki was always a community project! Maybe it was too hard to get an account there, but than we should work on solving that. Why should users be disallowed to update developer documentation? There's almost never enough time to write developer documentation and I'd say everyone willing to work on it should be allowed to do so. After all (at least with MediaWiki - I don't know about gitlab wikis) it's trivial to revert changes if they ever should introduce wrong information (which I assume to be highly unlikely). If you really intend to create a wiki space for users (I'm unsure about the content that might go there... and if I'm unsure how should users know?) then simply have that inside one (and only one!) Wiki. (MediaWiki could offer categories, subpages or even an own namespace for that)
#7 - Feature requests and wishlist changes, eventually will move into a future project management system on the website (I envision something that couples bug tracker style commenting with wiki like editing within a Blueprints-type tracking system). This is probably a few years out though so we'll need to keep using #4 devel wiki in the meantime.
What's wrong with the current approach of having that in the normal bugtracker (aside from the obvious shortcomings of Launchpad itself)? If we move to gitlab we could simply use gitlab issues for that (they allow markdown which should be enough "wiki-like" editing). Why try to create even more infrastructure for something that we already have plenty of solutions for free? Don't get me wrong: What you're envisioning sounds cool, but in practice I think it just won't work. Where should we take the developer resources from to implement such a system? Where should we take the resources from to triage all these things (I guess this will ultimately fall back to the bug team)? How do you expect users to properly differentiate between bugs and feature requests when even developers sometimes struggle to label some request. I really don't think a separation between bugs and features will work unless there's an easy way to transfer between them (in my own projects on GitHub I simply use "bug" and "enhancement" labels for that nowadays as it's usually the best approach to assign this status when triaging a request).
Let me know what you think, and please poke holes. If there are no red flags raised, we can proceed with this plan subsequent to our move to git.
Thanks, Bryce
I hope you won't take any of that personal (it's certainly not intended that way!) but I really don't feel this is the correct direction...
Best Regards, Eduard