Hi. Once again we are glad to remind you of the upcoming http://developers.google.com/season-of-docs. OpenMRS has successfully participated in this program for the previous two years as a mentoring organization, and it is another grand opportunity to apply. This time round, there are some changes that were made by Google which we should embrace with a lot of wisdom for the benefit of our organization.
Changes made:
Season of Docs 2021 will allow open source organizations to apply for a grant, based on their documentation needs. If selected, open source organizations will use their grant to hire a technical writer directly to complete their documentation project. Organizations will have up to six months to complete their documentation project.
Technical writers interested in working will submit proposals directly to the organizations, and will not need to submit a formal application through Season of Docs.
Participating organizations will help broaden our understanding of effective documentation practices and metrics in open source by submitting a final case study upon completion of the program. The project case study will outline the problem the documentation project was intended to solve, what metrics were used to judge the effectiveness of the documentation, and what the organization learned for the future.
The application deadline is March, 26, 2021, and we have not come up with project ideas yet. It is for this reason that we ask each one of you to come up with potential project ideas based on your squad needs to ease our application process.
respond to a documentation problem our community faces
help us achieve our documentation goals
can be completed in 3-6 months
It would be great if the project we decide to submit would leave us with templates or tools that can be re-used so that our community can maintain the output.
There are 3 specific topics I would like to propose. All focused projects:
Upgrading OpenMRS from 1.x to 2.x: This documentation would support the many implementers who need to do this but need help getting started. This should be a very clear toolkit with things like how to get started, analysis tools, scripts you can run, common problems encountered. The technical writer could work with the artifacts and guidelines we generated from the Rwanda EMR upgrade recently. @dkayiwa what do you think of this, esp. based on your recent experience supporting the Rwanda upgrades?
This seems like a massive community need that we’re not filling with any dedicated people at the moment. @janflowers recently estimated that 60-70% of OMRS sites are on 1.x (!!!) - that tells me we need a robust set of tools and guidance to help more people move onto 2.x as painlessly as possible, and one day, 3.x.
Getting Started with 3.0: How to Develop with Microfrontends and Carbon The Engineering leads for the MFE squad, @florianrappl and @bistenes are very interested in technical writing support for this. In the meantime it’s basically whomever can update these existing documents: Our wiki overview and our MFE GitHub dev guide. I’m doing my best to update these as often as I can but my time and knowledge is limited. A skilled technical writer could pair with our devs to deal with the knowledge/documentation debt, and work with the squad to set up expectations for when, where, and how the dev documentation is kept up to date.
Getting Started with QA: @k.joseph and @christine were just mentioning the other day that we need a better QA onboarding guide, so that new contributors can be rapidly and clearly onboarded and start contributing to things like Selenium and Cypress tests, or writing the test scenarios.
A few ideas discussed at last week’s Academy Squad meeting:
4. Improve the OpenMRS Knowledge Center. This project would document, organize, and publish developer/implementer skills, knowledge, and associated content to our Wiki’s Knowledge Center and Google Drive, with the overarching aim of using these to create OpenMRS Implementer Academy or Developer Academy materials. This project could consist of any or all of the following three parts:
1) organizing dev/implementer skills + knowledge and publishing them in a user-friendly format on our Wiki’s Knowledge Center,
2) gather relative content and organize/publish content in a resource library (Google Drive?) and linked to our Wiki’s Knowledge Center, and then
3) leverage the outputs of #1 and #2 to develop a suite of sessions/modules for an Implementer Academy or Developer Academy.
All three sub-projects would involve close collaboration with SMEs, developers, and implementers in the community (and specifically the Academy Squad). The third sub-project would involve working closely with an instructional designer/curriculum developer.
At Tuesday’s Documentation Team call, we discussed the project ideas above and identified a fifth potential project idea (that combines #1, #2, and #3):
5. Sustainable OpenMRS Getting Started Guides
The aim of this project is to sustainably create an easy to maintain suite of Getting Started Guides. Potential guides include: “Getting Started with 3.0: How to Develop with Microfrontends and Carbon,” “Getting Started with Quality Assurance,” “Getting Started with FHIR,” and “Getting Started with OpenMRS Upgrades.”
Our expectation is that the technical writer will:
Create a “Getting Started Guide” template and/or guidance that the community can use to develop other Getting Started Guides
Create the “Getting Started with 3.0” Guide, which will also serves as an example
Mentor 1-2 aspiring Documentation Fellows in our community on developing quality Getting Started Guides.
Each Documentation Fellow will be expected to complete a Getting Started Guide as a demonstration of their skills.
What happens now? We need to hone in on a single project idea to include in our GSoD proposal - and we want YOUR help!
Please review the project ideas above and vote for the one project that you think is high impact, has high value for our community, and maximizes the use of resources.
#1. Upgrading OpenMRS from 1.x to 2.x
#2. Getting Started with 3.0: How to Develop with Microfrontends and Carbon
#3: Getting Started with QA
#4: Improve the OpenMRS Knowledge Center
#5: Sustainable OpenMRS Getting Started Guides
0voters
We’ll close this poll on Monday, March 8 so that we can move forward with proposal development and meet the March 26 submission deadline.
As much as 3.0 documentation will be super important in the near future, I think there are enough people working on 3.0 that we can push each other to write decent documentation. However the need for 1.x-2.x upgrade docs is enormous and no one is going to just sit down and write those without specific funding.
Agreed that there is a huge need for upgrade documentation and guidance. As additional context, we worked on a Upgrade Toolkit with the team doing the RwandaEMR. I think it could be easily generalizable as it includes a lot of links to supporting documents - including resources from other OpenMRS distrubutions who upgraded from 1.x => 2.x. So to me, the question becomes: how much work will it take to expand the toolkit and make it generic?