I added a column “Q3-2016 Status”, and I put “DJ” in that column for the ones I’m proposing as ready-to-go. (We should have a better process than this, but I don’t want to figure that out now.)
Let me call out one bigger change: I switched “KenyaEMR Distribution” to the broader “Country-specific Distributions”, and I expanded the blurb to also mention Mozambique and Uganda. This is more in line with what I think Jan and I would say from the Distro team perpspective. (But if someone thinks we should actually be listing these distros individually, we could take that approach too.)
If you’re considering OpenMRS in Kenya, Mozambique or Uganda, you will want to look into KenyaEMR, eSaude, or Aijar (check name), respectively, and see if those distributions meet your needs, before considering one of the general-purpose OpenMRS distributions.
I’m sad to see that nobody has touched the document since I worked on it a month ago.
I propose that we spend next Wednesday’s design forum (Sept 7) doing a final review of our draft document, and we move to publish our first Tech Radar ASAP.
Sorry I haven’t been able to work on this lately. The (incomplete and non-functional) code that I’ve written is here. I’ve attempted to use tabletop to load data directly from the Google spreadsheet, and display it using an old radar rendering implementation forked from someone at Thoughworks.
I’m not sure when next I’ll be able to work on this, so if anyone wants to take a look, they’re welcome to use what I’ve done or start from scratch.
We are almost there! There are only two things left to do, then we are ready to publish:
Update the Blurb to use markdown (and incorporate the link). I did the first 5 of these, but need some mindless help with the rest. Specific steps are:
the first mention of the technology itself should be **bold**
whatever was in column H should be incorporated as a link: [label](url)
when you’re done with an entry, write DONE in column H
We need to fix the bug that requires us to have something in every category+recommendation. This requires checking out the code and debugging.
I noticed that it’s not actually required for the last quadrant. I don’t know if that matters.
When you check out the code it’s not enough to just open the index.html file in a browser, you actually need to be running a web server. (I haven’t looked into why.) Quick way to do this is something like npm install -g http-server and then http-server from the root directory of the code
If I remember correctly, the bug occurs when placing the Adopt/Trial/etc labels. I believe the code is trying to calculate a y-offset based on the position of the previous label + the number of items below it. If there are no values then there’s some kind of null- or zero-related error. I haven’t looked at the code in a while though, so I could be wrong.
Now we need to decide how/when to release it. Personally I think that after people have had a chance to review over the next 3-4 days we can just post it. (I guess to Talk, with a blog post, a tweet, FB post, etc.)
However, looking earlier in this thread I said:
At this point, we’ve had the draft spreadsheet posted since May, and there has been regular activity on this thread (from the usual suspects) so I’m not really sure why socializing it on a dev call before releasing it is necessary. (@r0bby, you were the one I said it to at the time, do you think it’s helpful at this point?)
As a note, ThoughtWorks has now released an open-source tool to visualize the radar (which you can either self-host or have hosted by them). We should migrate to this at some point.
