Ok, thank you @wyclif , that I have already been doing and we are continuing on that track.
That may indeed be a good case @mksd as it is a much more confined scope and it may be easier for the students (and me ) to get an overview. I will look into it in more detail. Developing a more detailed roadmap certainly sounds like a good task for the Requirements Engineering course (Jan-May 2018). But not sure whether that fits your timeline or you wanted / needed that earlier. Were you envisioning that over the next 6 weeks or rather a few months from now?
Would you be willing to serve as our point of contact for this? And you said there is a broad roadmap envisioned. Is there any of that documented or how can we elicit the information for that? Meeting minutes of IRC chats? Talking to you over Skype?
Yes I would have envisioned the detailed roadmap to be set out within the next 6 weeks. But it doesn’t have to be. I would rather have imagined that by end of May a new version of VDUI would be released. Meaning that the whole development cycle would have then been performed.
What I meant to say is that you could certainly use VDUI to cover multiple types of assignments, from outlining a clear set of requirements to actually releasing new features down the line.
It’s been written here and there on Talk. So I could gather everything in one place, maybe just in a Google Sheet or something? And this would be a starting point for a todo/wish list. This list + analysing the current state of VDUI (so at runtime) could kick start the engineering of requirements.
How does that sound? We can certainly discuss this over a call as well, please PM me your Skype ID, I’m on CEST.
@mksd Thank you for the additional details. Ok, I can work with that. Yes, pulling everything together in a Google Doc would work well for me. Sure, I’ll PM you my Skype ID.
@mksd following up on our Skype call today where we established that I ask my students about their interest in working on VDUI and get back to you. Answers:
- 2-3 yes to interested on working on a roadmap
- 8-9 yes to interested in replicating and reporting bugs
- 7-8 yes to interested in fixing bugs and developing (these students are a subset of the 8-9 yes above)
So please do gather all the information for the roadmap in a Google Doc and share the access with us. I will have a small team working on the roadmap and a larger set of students on fixing issues and implementing.
That’s fantastic news! I’m really glad that this project caught their interest!
Yes as agreed I will gather all items in one Google Sheet. And I guess we should call this module “Attachments” from now on then, and no longer “Visit Documents UI”. See this thread from here.
Sounds great! Looking forward to this collaboration!
@twinkleflip Great that this is moving. I would also like to suggest that part of the deliverables also include documentation on how to use the module being developed which is a usually missed aspect of software engineering/development but a very important aspect for users. This is a cross-cutting effort across all the groups of students and is highly collaborative too.
Yes, it is a very important aspect, and we can already see in the distribution of people interested (and voicing enthusiasm) in coding versus writing roadmap why documentation is often ‘missed’.
And that’s why I need to teach them to still do it, so I’ll advocate for this. There is a good start provided in the readme file, and I think we can get some good user documentation produced.
Where shall we put this while in the making? Are drafts on Google Docs with links in here a good way to keep things traceable and accessible while in draft stage?
Update: 3-4 potentially interested in documentation. You mean to guide future users, right? Where apart, from the readme file on github, is the module (partially) documented so far? Also, pointers towards what the format of the documentation should be like? (Maybe a good example to point to from another module?)
Historically OpenMRS modules have been documented in Documentation \ Home \ Modules on the wiki.
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!
So… this is where everything starts
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?
So from my side:
Refactoring into Attachments
Transfer to OpenMRS GitHub repo
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.
Creation of the JIRA project
Transfer our in-house JIRA tickets to ATT
Done. See here
- Setup of a Bamboo CI pipeline.
I still need to do that.
- Students should join Talk.
- Students should join JIRA.
- Students should join channel openmrs on IRC Freenode.