Despite my belly-achings about there not being enough documentation for code and whatnot, I’ll agree with this. @rishabh.malhotra I think a good compromise would be to go the route that Facebook, the creators of Reactjs, have gone and make the documentation primarily about what’s a fixture in the app and then what breaking changes are being planned that contributors need to know about ahead of time. They’re not fully open about every single thing to the “T”, but offer enough that guys like me are happy.
It is impossible to fully keep up with what’s what with the limited resources this project has in its current state but I have more of a gripe with transparency than anything else. When I say transparency, I strongly believe in open discussion about the little things that could always make this project better, even if they never go anywhere. And this project is a lot more transparent than my initial thoughts, so not as huge of a problem for me.
Writing code documentation is very important. What I do now is what @rishabh.malhotra is doing. But it is hectic and takes some time. Writing code with documentation helps a lot. Especially when it is an open-source project, a lot of collaborators with different levels of experience will be working together and good documentation makes everyone’s life a lot easier. I believe that when a project is said to be open source, Documentation for the project is assumed. I’m 100% for adding docs to Joplin.
As discussed above, the best option would be readthedocs. It is very easy to use and documentation becomes very easy. Initially implementing would be a bit difficult because there are a lot of functions that already exists in the code, but it should be alright.
Similiar to Google Summer of Code, there is Google Season of Docs. I think Joplin should participate in the next one.
If we do plan to implement documentation right now, I’m would love to work on it as well.