We've been discussing moving to sphinx for different reasons, namely that translations would be easier. We even asked the sysadmin and they confirmed it is possible to have something that runs sphinx every so often over a git repo's content and puts the result in a spot accesible by the docs.krita.org url.

We already expect that even if we take the dry mediawiki files, and use pandoc to convert, still all the links will need to be manually checked as well as having the macros we use on the mediawiki converted to the appropriate sphinx functions. This will take at minimum a month. We do not have time for that right now, so such a move would not happen until after 4.0 has been released at the very least.

If you wanna help right now with that, you can help with research:

1. I am looking for good RST and Markdown editors that windows users can use, as to help the contributor's guide.
2. Similarly, I am looking for nice idiot friendly sources on how to use RST.
3. We have apdidocs in the krita source, setup so they can be extracted nicely with doxygen. I have seen it is somehow possible to use a sphinx extension called "breathe" to use those to produce sphinx output. I have attempted to get at the least the python api docs output in sphinx but was not capable of doing so. So if you are feeling like tinkering with tech, this might be an interesting problem to tackle.

Either way, I made an official task for the move here: https://phabricator.kde.org/T6714
You can login to phab with your forum account and comment.

TheraHedwig wrote:1. I am looking for good RST and Markdown editors that windows users can use, as to help the contributor's guide.
2. Similarly, I am looking for nice idiot friendly sources on how to use RST.
3. We have apdidocs in the krita source, setup so they can be extracted nicely with doxygen. I have seen it is somehow possible to use a sphinx extension called "breathe" to use those to produce sphinx output. I have attempted to get at the least the python api docs output in sphinx but was not capable of doing so. So if you are feeling like tinkering with tech, this might be an interesting problem to tackle.

For 1:
- Atom (Can do both Markdown and ReST with Live Preview)
- MarkdownPad (Markdown only)
- Remarkable (Markdown only. Some features of the Linux version, like Live Preview, are still under development on the Windows version.)

For 2, a quick search amounted to nothing a person who has never programmed or used that type of text editing before was found. Even the various 'Quick Reference' and 'Cheat Sheet' documents I found often spend unnecessary amounts of time blabbering about Sphinx and comparing the structure against Python.

MR4Y wrote:For 1:
- Atom (Can do both Markdown and ReST with Live Preview)

+1 I actually forgot this one, it is developed by github/github users.

MR4Y wrote:For 2, a quick search amounted to nothing a person who has never programmed or used that type of text editing before was found. Even the various 'Quick Reference' and 'Cheat Sheet' documents I found often spend unnecessary amounts of time blabbering about Sphinx and comparing the structure against Python.

Well, reStructuredText is a python thing(docutils) so, yes it follows some of the same ideas as python in places, such as use of indentation. Even wxPython wrote their own page for differences and such for the docs, but I still wouldn't call it "idiot friendly", just more related changes to *their* docs on top of vanilla rst. A basic knowledge of the syntax would still be required for any language/markup, its just that some don't have a GUI to help with stuff like a "bold", etc like the wiki does as certain things can't be nested in rst as a rule. It is not Rich text.

For the most part rst is close to markdown, but with programming capabilities(like custom directives) similar in aspect to python indentation and some strict syntax rules.
The nice thing about sphinx is that is was written for the python docs(yea two python libs now, lets add another...) and when building pretty much prints out all the errors it comes across, tho for a person new to using a console, may find this workflow a bit old fashioned, but it does pinpoint problems fairly well(it will pick up all interdoc links that don't exist or are broken).

Coming up with "kindergarden" style docs might be hard-written, but I think with enough eyeballs on the situation, it is sorta possible. Examples within examples will be needed(like the cheatsheets), but with a more hands-on each situations approach.
Edit:
...and the kindergarden docs would likely be written after the wiki has been fully ported, so as to note all differences/problems incured by each porter.

Edited OP for consistency with current 2018 fundraiser. 2 Bounties have been claimed. Therefore 2 days worth of hard labor will be donated.

Dev of the year: Dmitry; Selections
Runner up: Woltherav; Docs

Not sure if i'll be able to get the donations all compiled in one in time, but it will be there. Our papercut's applies to the subjects addressed.
Thanks Everyone! Wish you many more successful fundraisers in years to come.