However I personally prefer packaging and versioning the documentation with the code base. I have done that with the Initializer module (see here) and I find it a lot better. It becomes a habit, every time I commit, to keep adding/updating the README. Of course in the case of the Initializer it would deserve to be split, but you get my point.
Initializer is a different ball game since it is a UI-less module, a pure API module.
In the case of Attachments (new branding ) there is a double need:
A user guide. So something that elaborates on what exists and runs the users through how to use it. Typically with a lot of annotated screenshots.
A developer guide that outlines the current architecture, used patterrns and data model ; and that explains how to keep extending the module.
So⊠I have compiled a list of items that represents a draft roadmap for Attachments. I am provding an edit link here:
@twinkleflip let me know if/when you would like to discuss this, possibly with the students then?
Others, feel free to add items that I may have missed.
Thank you!
We will talk it over tomorrow, Tuesday, in the group and then get back to you.
Our class meeting is at 6pm Pacific time so I am not sure whether that is a feasible time for you - actually Iâm pretty sure itâs not, itâs (I think) 2am for you.
Let me know though.
No sorry I wonât be able to attend, but perhaps could you try to convince them to hop in a call any day after your class on a time that would work for everybody?
Did you go through the file, does it look like there will be enough to discuss with them?
Yes, I did go through. So, the main question I have is âwhat about the descriptions of lines 10-25?â
There is rather little to chew on, and so today we will be going through the linked references in OpenMRS Talk and expanding on your descriptions and then asking for feedback.
We will start to structure the information into a requirements specification and roadmap.
The problem with âon a time that would work for everybodyâ is that such a thing doesnât exist.
Most students in this program work full time and only come to campus for class in the evening two or three times a week.
One more question: How do we filter out the issues of JIRA that relate to VDUI? There is no issue tracker linked in the github repo, and we have trouble finding the current set of issues (for the subset of students that would rather work on that). Thanks!
What I threw in this file is a mix of our in-house existing issues and a bunch of new ones collected all around Talk. So here are the next few steps:
Refactor 'VDUIâ into âAttachmentsâ.
Move the - then renamed - Attachments module to the OpenMRS GitHub account.
Request an ATT (for Attachments) JIRA project to be created.
Create JIRA tickets from whatâs in the Google Sheet (and quickly deprecate the Google Sheet).
I would say that 1, 2 and 3 are on me.
4 is going to be mainly for your class, except for the couple of issues that I can copy right away from our in-house JIRA.
All of my tasks above are fairly quick and easy except for 1. Deep down renaming of an OpenMRS module can be a bit tricky, but anyway doable of course. What would be the latest acceptable date for me to deliver this?
Also I intend to jump to version 2.0.0-SNAPSHOT, in anticipation that all this leads to a 2.0.0 version of the âmodule that helps managing attachments (formerly known as VDUI in its 1.x form)â, does that sound good?
@cintiadr, not sure if you will be the one dealing with this, but I just created the helpdesk case # 42258 regarding the creation of a new ATT JIRA project. Thanks in advance to the infra/helpdesk team for helping!
Ok, well, the sooner the better, because there are people who want to work on the specs and people who want to work on the code.
Could you have it done by Thursday night? Then we could get on it this week still, which was my plan.
Thanks!
What is the severity of the individual issues?
We only know the minor improvements, but the other themes donât have a clear level of severity.
For developer documentation: This requires a high level of familiarity with the code unless you have exceptionally well structured and detailed commented code and design specifications. Otherwise not sure we can do that for you.
Where can we find coding styles or guidelines for your module? Are you just using general OpenMRS coding style (link to that?) or are you more specific?
We assigned the issues to detail (column documenter) and as soon as the JIRA is ready, we can put them in there and ask questions about whether we interpreted all of them correctly.
Cheers!
Yes I think so, I just went through most of it and Iâm currently testing it. By tomorrow end of (my) day should be ok.
I will add what I anticipate would be their JIRA type (ranging from âtaskâ to âstoryâ), this will help give an idea of the scope of each.
And I will already copy those that can be from our in-house JIRA to the OpenMRS JIRA.
The JIRA project exists, and the GitHub project will as soon as Iâm done with the refactoring. Do they all have an OpenMRS Talk and a JIRA account?
Transfer to OpenMRS GitHub repo Done.https://github.com/openmrs/openmrs-module-attachments There might still be variable names that refer to visit documents rather than attachments or other small glitches like that. Those should be corrected as we stumble upon them.
I just (really quickly) distinguished between tasks and stories in the Google Sheet. Some of the stories are big and will be split into multiple tasks. So the initial assigneeâs scope of work for those stories might just be to kick start the needed pre-analysis. It would be unfair to expect those students currently assigned to them to deliver the entire stories.
) there is a double need:
