Thanks for the correction my assumption was someone in coding team. Let me work on it. I have added some members like @burke, @dkayiwa, @ball, @ssmusoke for the purpose of consultation.
to start documentation, I am imagining the steps to be using GIMP for screenshot modification, and using open office for writing the tutorial documentation of how to use the screens of the reference application. Any comments?
Thanks so much for leading this effort. Itâs not clear to me if this is about general documentation (which your descriptions imply) or specific to reporting (REPORT-847 is a reporting module ticket). If you are focusing on documentation on the reporting module, it might help to call that out in the sprint. If you mean to address documentation more generally, then the JIRA ticket is misplaced. Iâm guessing itâs the latter, given the ticketâs summary: âEnsuring all openmrs documentations are updated.â
When creating a ticket in JIRA
âStoryâ tickets should be fairly small (ideally <2 weeks of work) with clear acceptance criteria. A common story would be something like âAs a end user of the reporting module, I should be able to easily search for my saved reports.â An âEpicâ is used for a bigger target (may comprise multiple stories), but should still be an arc (i.e., have a clear end goal) like âComplete Developer Manual 2.0â.
Itâs important to put it in the right project. In this case, the problem may be that we have no general âDocumentation for the Communityâ project. So, perhaps we should create a new JIRA project for this category? In fact, from what youâve said, Iâm guessing youâd like a new Documentation project and a scrum board in which to do sprints for that project. If so, Iâd be happy to help walk you through requesting a new JIRA project. Alternatively, we could use TODO lists in the wiki.
Cheers,
-Burke
When approaching our documentation, Iâd like to point out the resources we have. When working on these areas of documentation, it would be more helpful to improve/update these existing resources rather than create duplicate efforts:
Getting Started As a Developer (om.rs/gettingstarted). This is the wiki page to which we direct all new developers, regardless of their interest (developing a module, leading a new distribution, just curious, etc.). Ideally, this should be a fun & instructive starting point for any developer to get involved in OpenMRS development.
Developer Manual (om.rs/devmanual). This is meant to serve as a useful & printable manual for new developers to help them get started. It is hosted in github and uses GitBook format.
Implementer Guide (om.rs/guide). This is meant to serve as a useful & printable manual for new implementers to help them get started. It is hosted in github and uses GitBook format.
@burke I guess opening a new JIRA project is exactly what we need. It will help to avoid confusion between volunteers when some people do the same work without being aware of this. Also, it will be easier to keep track of documentation in the future, since there is going to be one place for all the issues related to it.
Does documentation include adding simple java classes for the screens of archetypes of OpenEHR. Example below:
For the body mass index, I tried this draft for the java document of body mass index. I thought I may share it with you to add it alongside the xml format, as it may be of value to anyone trying to use the archetypes.
I highly appreciate your comments,
Regards,
Mona
package OpenEHR;
public class BodyMassIndex {
public static void main(String[] args) {
// TODO Auto-generated method stub
int weight = 105;
double height = 1.75;
int age = 34;
float heightPowerTwo = (float) Math.pow(height, 2);
System.out.println(weight / heightPowerTwo);
int weight1 = 105;
double height1 = 1.75;
int age1 = 34;
float heightPowerTwo1 = (float) Math.pow(height1, 2);
float BMI = weight1 / heightPowerTwo1 ;
if (BMI >= 29)
{ System.out.println(âoverweightâ); }
else
System.out.println(weight / heightPowerTwo);
}
float height;
float weight;
int age;
String name;
public float getHeight()
Apparently No. After consultation we pushed it to next year which is this week. Though time and date not slated. Thanks for asking I will ensure I set everything right before the end of tomorrow.
Could we use the next scheduled design call to discuss the approach we want to take, What needs to be improved (are we satisfied with the status quo?) etc.