Content
OpenProject documentation
Added by Ivan Griggs almost 4 years ago
I have looked at the online OpenProject documentation and have noticed the following that I thought I might fix. I have checked the dev branch on GitHub, looking at the last commit to see the markdown text.
* Location: Release 11.1 / Getting Started...
(1) "Sign in and registration" page: the "sidebar_navigation" bar section is showing as text. In GitHub the top few lines appear to be different to other pages (no "---" lines).
(2) "My Page" page: section "Configure the view of a widget" shows "<div class="glossary">" in page text. The README page in GitHub is missing other text, although the markdown seems correct.
* Location: Release 11.1 / User Guide...
(3) "Manage members" page: section "Roles and permissions" shows "</div>" in page text. The README page in GitHub does not show the header "Groups" correctly. I am not sure of the markdown syntax being used.
* Location: Release 11.1 / Development
(4) "Development concepts" page: in the table, State management description spelling "hanble" should be "handle". This is the same on GitHub.
Error 4 looks easy to fix. I am not sure about the others.
The markdown appears to be converted into HTML with the table at the top having a purpose. Is there a "specification" of how a page should be formatted in the markdown so that it displays correctly?
Replies (3)
Dear Ivan,
Thanks a lot for pointing this out! I fixed this. However, for (3) I could not identify errors.
(2) was due to a wrong quotation mark:
Next time please feel free to create a pull request on GitHub to change such errors (but this way it's great, too!).
Kind regards
Matthias
Hi Matthias
Thanks for your response. I have checked what you have done and that helped me to understand a lot more about the documentation change process. I wasn't sure about the commit message and the target Release. I'll have a go at the pull request route.
What is the optimal number of changes that I should make before I submit a Commit or Pull Request?
I would suggest using pull requests (as you already did), as this makes a review process possible. I recommend collecting some commits belonging to the same topic before issuing a pull request.
Kind regards
Matthias