Documentation work
So a lot of work went into cleaning up the issue list on github the last few weeks. I hope we can keep up the good work and make a real effort of closing tickets by submitting pull requests.
As for the next period i would like to suggest we take up on all the "docs" related tickets. It would be great if we could get all the docs tickets fixed before 1.10, so we can close down the old docs.elgg.org.
That means i have to learn how to update the docs, so if someone can give a small recap on how we should do it (and some links on nice tools, syntax etc for it).
Also, should the commits for docs be on the 1.9.x or on the 1.x branch?
Maybe to prevent multiple people working on the same ticket, you could self assign, so everyone else knows you are working on it.
Do you agree with this suggestion?
- Juho Jaakkola@juho.jaakkola
Juho Jaakkola - 0 likes
- Evan Winslow@ewinslow
Evan Winslow - 0 likes
You must log in to post replies.When converting the old wiki docs I usually start with online tools (e.g. https://livesphinx.herokuapp.com/) and then I finish it up in a local Sphinx installation, that can be configured to work just like the docs at learn.elgg.org.
Introduction to rST syntax: http://sphinx-doc.org/rest.html
Docs should go to the stable branch.
Thanks for all your work getting tickets closed. We've reduced our open ticket count by ~20% in the last couple weeks and I believe a majority of that credit goes to you, Jeroen.
Check the .travis.yml file for the exact up-to-date commands used to install and build the docs. If that doesn't work, come on back with the errors that you're getting.
Would be great to finally shut down docs.elgg.org -- it is still showing up in search results when I'm looking for details sometimes.
+1 to put the docs on current stable branch (1.9 as of this posting).
Good idea to assign tickets you're currently working on.
Also I'd remind reviewers that we shouldn't nitpick at quality when porting docs over from the wiki. Let's just get them transferred and get docs.elgg.org turned down. Then we can review the state of affairs and see what's most needed wrt reorg or quality improvements. That presents docs translators with a small amount of churn but I think based on our development pace it won't actually be that bad (and there aren't many docs translators anyways).