Walk through of an evaluation of the OpenMRS project

There are many criteria which should be looked at when determining if a project is appropriate to use in your class. These criteria are broken into two groups - mission critical and secondary.
I am using these criteria to determine whether the OpenMRS project would be a good fit for the software engineering senior design course in Spring 2017 at CSULB.

Mission Critical Criteria-Viability

1. Size/Scale/Complexity - An ideal project should be neither overly simple nor overly complex.
   1. On the OpenMRS web page (http://openmrs.org/), there's the OpenMRS Wiki (under Other OpenMRS sites). From the menu on the left expand the Developer Guide and the Getting Started as a Developer options and then look at the Technical Overview. From examination of the technology stack, the architecture looks modular and further search shows it is documented elsewhere on the site. This provides a first look at the complexity of the application and the number and various different technologies involved.
   2. Based upon the results from OpenHub (gathered in the FOSS Field Trip activity) and the information from the OpenMRS Technical Overview page, think about the size of the code base and how many different technologies and layers are involved in the application. What would you score this project for size/scale/complexity on a scale of one to three where one is "low" and three is "high"? Probably a medium because it could be more complex but it is certainly sufficiently complex to learn the ropes and to have to focus.
2. Activity - To support student participation a project should be reasonably active. Number of commits can be used as an indicator of activity.
   1. Based upon the number of commits (gathered in the FOSS Field Trip activity) would you consider this project active? This project can be considered as active because it had on average more than a commit per day over the past 12 months, so that is a good basis for assuming that the activity will also continue for a while longer.
3. Community - A suitable project has an active user community. While it is difficult to quantitatively evaluate the activity of a user community, some indicators include a regular history of project downloads and documentation updates over time, current activity on user mailing lists, and testimonials on the project web site.
   1. Examine download activity
      1. Go to sourceforge.net and enter OpenMRS into the search box.
      2. Choose OpenMRS from the search results.
      3. Click on the number of downloads that is listed on the project page. 976 downloads this week is pretty good!
      4. Change the date range to give a graph of downloads over the last year. 72,490 downloads in the last year. This certainly makes for a large enough user community.
   2. OpenMRS has begun migrating legacy mailing list activity to OpenMRS Talk. Examine discussion activity: The user and developer forum is very active and well moderated.
   3. Examine the IRC logs: The IRC logs show good communication, high activity, and good netiquette.
   4. Based upon the download history, discussion activity, and IRC activity, do you feel this project has a good community? This project certainly has a good community, multiple leaders, highly spread developer community, everything that seems to be necessary for a community to thrive.

Mission Critical Criteria-Approachability

Here you are evaluating a project's on-ramp to contribution, scoring as follows:

1-Insufficient-Few or no pointers on how to become involved.

2-Sufficient-Suggestions about how to get involved other than contributing money with accompanying high-level instructions.

3-Ideal-Obvious link to get started, list of suggestions for things to do and detailed instructions.

1. Examine project on-ramp.
   1. Link to getting started - The website has a Get Involved page with links to ways you can contribute and share your ideas.
   2. Each of the links (Develop, Test, Document, Translate) contain more detailed information about what and how you can contribute.
   3. The Getting Started as a Developer page contains a detailed list of how to get started including a list of introductory issues.
   4. Detailed instructions - The Developer Guide contains instructions and information in many areas including process, architecture, tools, and developer documentation.
   5. Based upon the resources you looked at, how would you rate the approachability of the OpenMRS project? This project certainly has everything in place for thriving development, and I would rate it as very approachable. Developing, testing, documenting, translating are all options for contributing. Sharing is also encouraged via connecting, suggesting, spreading the word, or just getting an OpenMRS ID.

Mission Critical Criteria-Suitability

1. Appropriate Artifacts - Since evaluation is dependent on class objectives, in this example we'll assume the objective is to learn the process of working in an authentic development environment by contributing bug fixes to OpenMRS.
   1. Opportunities to contribute bug fixes - Examine the issues found at the bottom of the getting started as a developer page. The introductory issues are categorized into curated and non-curated, which means that there are some that have a thorough description of how to solve them, while others don't. There are 39 curated and 70 uncurated introductory issues listed.
   2. Documentation on how to contribute bug fixes - On the Tickets pagethere is information on how to create and work on an issue, including links to coding standards and the code submission process. 
   3. Based upon the number of bugs suitable for students to tackle and information on the process of how to submit bug fixes, do you think this would be an appropriate project for your students? Based on the number of introductory issues, even though I think my students would especially like to start on curated ones, I think this would be a suitable project.

2. Contributor Support - Does the project have a high volume of guidance to help students as they learn?

1. Communication Tools - Communication tools are directly available from any of the Wiki Spaces (Documentation, Projects, Resources). The Resources page contains links to OpenMRS Talk and IRC Chat, as well as links to group meetings (under Events), and training opportunities.
2. Web Presence - Examine the IRC logs. There has been plenty of activity during the last week.
3. Operating Processes - Links to information about coding standards, the code submission process, and commit privileges can be found on the How-To Submit Code page. The process for making feature requests is available on the Tickets page. These processes are well documented.
4. Response to Questions - Review a few of the posts on the OpenMRS discussion platform. Posts to this forum seem to receive timely and supportive responses.
5. I would you rate the support that newcomers to OpenMRS receive as really good.

In summary, it looks like the OpenMRS project is a very suitable project for the course according to the mission-critical criteria. The project is viable, approachable, and suitable. The community is very active, very supportive, and very well documented. The cause of the project is to support healthcare worldwide. It is a medical records system.

For the secondary viability criteria, for understandability of the domain, the required domain-knowledge is not too complicated. Maturity, user support, and roadmap are all given as well.

Secondary for approachability, the types of contributions, the openness to contributions, and the friendliness to students also seem to be given.

Secondary for suitability, the project description is very accessible, the project is platform-independent, and the development features provide enough options for all students to find general as well as very specific issues.

So for the secondary criteria, the rating is also good for OpenMRS.