I think it is a good time to try to streamline the documentation process.
I am asking my developers to document their changes the following way:
- Make a short notice about the changes committed in the developers forum;
- Put more info (e.g., how to use the new functionality) on the oemr.org wiki where it is much better accessible;
- Put as many comments as possible (and appropriate) in the code;
- And add documentation to the CVS-package as well (in the Documentation directory).
Another nice feature would be to have end user help files inside the package.
Let me know if this is a good description of the documentation process. Feel free to suggest changes/additions. I will post the final version to the wiki and kindly ask everybody to follow it.
I will need to know which people to give write privileges on the wiki. I am very happy to add any and all contributors. (I had to shut shut anonymous because of phishing insertions in the wiki.)
I fully agree with Dr Bosman. While doing development with OpenEMR I’ve run across beautiful comments in the code and other places were a vast wasteland where I had to struggle through to determine what the code did. I find that comments embedded in the code are the best form of documentation for a developer. Be liberal with them, don’t hold back. Remember that the comments may increase the PHP file size but they don’t slow down the processing of the file when it’s called up.
Very soon I’ll be writing a manual for our Agency as to how to use the calendar and basic scheduling. Perhaps pieces of it could be added to the documentation in the wiki.
I will be more than glad to add this to the wiki. (Or even better, I will give you write privileges so that it will easier for you to maintain changes.
