Hi Martin,
Am 30.01.2017 um 21:16 schrieb Martin Owens:
Hi Eduard,
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...
That's my call actually. The machine is ancient and osuosl are itching to get rid of it. We're using it for very little compared to the machine's power and I'd prefer if it were possible to fold in our services to use the website and the gitlab wiki.
That's unfortunate but absolutely understandable. I guess moving to another server / a virtualized server was not an option?
*very* rare good and in my humble opinion we should abstain from
spending it all on administrative tasks like splitting, moving, copyediting, whatever.
The content doesn't need to be copy edited. A lot of pages need to be archived and I think a archiving by default position would be a good start. Take what we need, as we know we need it.
I'm disliking the term "archiving" a bit, see below.
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
Extensions shouldn't be in the wiki anyway. Either they're for user consumption and should be on the website (where anyone can post one) or if committed they should be documented alongside the codebase. If in the future we split out our extensions repository, that's a task for another day.
I think we're talking about different things here: As far as I can see the Wiki currently contains a) documentation on built-in extensions (that was the link), b) documentation on how to write an extension, and c) a list of third-party extensions. While a) is obviously user-facing and therefore would fit on the webpage I don't think it's complete enough yet and needs work. b) is even harder - personally I'd keep it in a Wiki so it can be improved continuously by everyone (as I'd prefer for all developer documentation), bryce would like to put it into the VCS's developer documentation if I understood him correctly and Maren even considered having it on the Website! Extensions themselves obviously do not belong in any Wiki.
#2 - Strictly user-facing pages in the wiki are moved to themain website. High level project info, roadmaps, user-oriented FAQs,
I'd vote roadmaps aren't user facing documents. They're develop documents. We may want to write news or campaigns about them for the website though.
but at that time a code change probably made it outdated or even
obsolete.
A lot of coder related documentation is actually in-line, some of it is build instructions, "getting started" that sort of thing. Generated docs aren't for committing and I expect we wouldn't actually have that many docs in the git repository, at least not separate from code.
But that'll be for us to proof as we see what kinds of pages are being archived out of the wiki. We'd only put things in the git repo if it made sense and I think Bryce is making room, even if the room isn't going to be used.
All right, that sounds reasonable. I was a bit afraid that we'd try to somehow put everything relevant into /doc but I honestly don't think that would work but instead only create a graveyard of outdated information that many people wouldn't even know existed.
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).
I'd just keep these on the GitLab. If they're developer related and people are collaborating, the markdown wiki should be fine. For faster collabs we can still use google docs and paste into the wiki when they get stable (by which I mean edit time goes into the minutes as apposed to seconds.
Don't forget on GitLab you can save User wiki pages, and I recommend we encourage their use for drafting if people don't want to muck up the project wiki.
Sounds good, but I assume the encouraging part will be vital. I don't think many people used their user page on the MediaWiki...
If you ask me that is actually the way I'd prefer and the only reasonable solution: Everything developer-related goes into a gitlab
Agreed, this is a good plan.
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.
No the media wiki content can be saved into a read-only directory on inkscape.org, so we can reffer to it but no editing. If edits are needed, then the content is moved to the right place.
This is something I'm very skeptical about: - How should people know where to search for Information if we have a half-dead Wiki and a not-yet-alive Wiki side-by-side? - How do we prevent potentially outdated information on the read-only page from being used in error (i.e. who would be able to delete/edit that information?) - If we put a huge sign on top "Warning! Outdated!" nobody will take that information serious (how could they?). If we don't people might not be aware they're browsing an archived read-only version of the page that in fact *can* be outdated. - How do you intend to motivate people to work on the new Wiki if there's "some" content already available on the old Wiki? (I'm imagining scenes like "there's some information on the old Wiki which is mostly up-to-date; unfortunately nobody's able to update the few errors since it's a read-only version; unfortunately we also did not have the time to transfer it to the new Wiki, yet").
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?
I agree. We have enough tools to do this without a MediaWiki of any kind.
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...
No, good concerns, highly appreciated.
Best Regards, Martin Owens
Regards, Eduard