Sorry for the late comment, but I definitely agree with Jennifer on both points. The Git-book is really nice looking, but a Wiki is so much more responsive to changes in procedures/formats/contacts/etc. And I’d definitely love to work with you on the background information, so you can focus on what’s specifically relevant to developers. We can chat today at the Documentation meeting!
2 Likes
Hi @jennifer @herbert24 @madhens, Sorry I couldn’t attend doc meetings for the past two weeks. I will try to arrange with my workplace so that I can attend next week.
2 Likes
Hey @rainbow ! I know your work schedule is very busy, but can I help you asynchronously with separating the information out into developer-specific and general-volunteer-information since that will help both of us. Feel free to reply here or message me with the best way for me to help you!
1 Like
Hi @madhens, that would be great! Thank you so much! I am thinking The architecture, data model, and create the first module would be good technical content to separate out for new developers. @herbert24, do you agree?
2 Likes
Here’s my thoughts on technical documentation goals:
-
One link: Send any developer new to OpenMRS to om.rs/gettingstarted, regardless of their skill level.
- Let’s try not to lose this
-
Quick start in 15-20 min: In 15-20 minutes, get oriented, an OpenMRS ID, an appropriate dev environment, and know where to find community/help
- I see this as the primary purpose of om.rs/gettingstarted, which is getting too long/wordy, IMHO. It would be great to find a way to walk people through the material in something more engaging than a 17-item list.
- I see this as the primary purpose of om.rs/gettingstarted, which is getting too long/wordy, IMHO. It would be great to find a way to walk people through the material in something more engaging than a 17-item list.
-
Hello World in an hour: Within an hour, someone with requisite skills can become a productive OpenMRS developer (e.g., a “Hello World” tutorial)
- This would be a great resource. Ideally, we’d have a choice of tasks (e.g., building a module, building a frontend, etc.), introducing module devs to the SDK and frontend devs to npm libraries and esm practices. But these could evolve with time and any hello world tutorial would do.
-
Reference: Reference materials to dive deeper into architecture, APIs, etc.
- Javadocs at api.openmrs.org, REST API at rest.openmrs.org, FHIR API docs at fhir.openmrs.org, and a well-organized OpenMRS technical reference on the wiki.
I agree that GitBooks, while prettier & easier to maintain than FOSS Manuals (e.g., edit directly via GitHub website) and markdown, introduces more maintenance and doesn’t offer enough value over the wiki to maintain it unless/until we have a clear need for creating a separate book.
2 Likes
@rainbow we do have some suggested ideas by @burke on how we can even have the docs arranged,we can pick a couple of things from that
1 Like
@burke, thank you ! Based on my own experience,I think 15-20 min to set up is a bit challenging though. 1 hour would be a big improvement, as from the survey we did, some people took days to set up.
1 Like
@jennifer, @herbert24, @madhens, @grace
I’ve put my project on the documentation Trello board. Please provide feedback on the drafts. Thank you!
2 Likes
Thanks rainbow,i am going to provide feed back there
@herbert24 The “Create Your First Module” instruction is here. However, I am not entirely satisfied. As it doesn’t provide any output. I need help in modifying the source code so that when the module is deployed to the server, there can be some minimal interaction, such as allowing the user to click a button to display a simple message such as “Hello World!”.
Another question is: should there be different types of first modules? Right now it’s just a reference application module. Should we add OWA, and platform modules as well?
1 Like
The draft for the new Getting Started as a Developer is here. @herbert24 @jennifer @burke @grace Please review and provide feedback, should any other content be added to it?
I’d like to take steps 9, 12, 13, 15-17 in the original document and put it into a separate document.
The community priorities and Introductory Issues should be in a separate document as well.
What do you all think?
Based @herbert24’s recommendation, the next steps are:
- Put all documents produced so far on wiki for newcomers to test them out.
- Look into developer stage document.
- Look into micro-frontend (Javascript) document.
- Look into OCL UI (REACT) document.
1 Like
Reviewing this and will add comments on your docs
@rainbow,some thing to note,this https://wiki.openmrs.org/display/docs/OpenMRS+SDK+Step+By+Step+Tutorials can be different from the one you are making ie https://docs.google.com/document/d/1iW5BA9XFoyRAs8Aj8jxsX1rFw5DjhDvyNGMTT7UvIn8/edit#, the first one talks about installation of sdk on the databases database in general,while the one you are making is specifically for the docker,i am available to talk more about this during the course of the week
1 Like
well this https://wiki.openmrs.org/display/docs/Step+4+-+Install+MySQL and this https://docs.google.com/document/d/1QHxIC9cC-dUdU7O6T0yQbWX1bCNsPiasHJHl7qqt7Ik/edit#heading=h.cu9r9swdjj7j ,same thing as the above
1 Like
@herbert24 do you want to have a meeting this week to talk about feedbacks? I missed the design forum meeting today.