-
Notifications
You must be signed in to change notification settings - Fork 45
PopHealth Change Management Procedures Guide
PopHealth is an open source project. Changes to popHealth can occur from requests made to the popHealth Steering Work Group and implemented by members of the popHealth Developer group. However, a significant number of changes are result of code contributions made by the members of the popHealth community. In those cases, the changes follows the Code Submission Workflow process to receive the approval and commit to the master branch of the popHealth source code repository.
The purpose of this group is to chart the roadmap for the evolution of the popHealth software suite. This working group will coordinate closely with the Developer group that will develop, test and commit new popHealth code that meets the strategic objectives set by this steering committee. The steering committee will also work closely with the user's working group to assure the strategic direction meets the evolving needs of the user community. Members of this group are stakeholders whose organization have vested interest in how best to use the popHealth to serve their customers. These organizations include both public government entities and private companies.
Individuals can make requests to the Steering Work Group for changes such as new features to popHealth. Documentations include business justfication, use cases description, and funtional requirement should be provided with the requests. If approved by the Steering Work Group, a follow-on request is made to the Developer group to access the resource requirements for implementing the changes.
The Developer group, upon receiving the request from the Steering Work Group to assess the resource required to implement the change request, will perform a technical analysis of the change request. This include reviewing the provided documentation and determine the types of development, i.e., front-end GUI vs. back-end business logic/database. Finally, the Developer group will provide an rough order of magnitude (ROM) estimate of the required effort to complete the implementation. The estimate should include number of hours, staffing, and infrastructure required for development, testing, and integration.
Base on the estimate provided by the Developer group, the Steering Work Group will decide whether sufficient resources are available to complete the task by a given timeline. In all cases, it is encumbent on the requester to provide the resources that will benefit the entire group. This include providing various types of the resources needed as delineated in the estimate. Only when there are consensus by all members who are contributing to the development of the change request will the change be approved.
The Steering Work Group will prioritize the change request in accordance with the available resources and required timeline for the completion of the change request. For example, if the change request completion date is set by a specific contractual agreement, the Developer group will provide best effort to complete the request by certain date.
Create fork from the Master branch to start a feature branch
- Small size feature update (~ preferably less than 100 lines of code)
- Follow Github Coding Style Guides - https://github.com/styleguide. This include CSS, JavaScript, and Ruby code style guide. Enforce coding style using jscs :Javascript, CSSLint:CSS, Robocop:Ruby style checker.
- Proper attribution based on Apache 2 licensing
- Include unit tests and functional tests
- Run coverage tool to show a minimum of 50% test coverage
- Documentation – updates to be incorporated into the User Guide, Installation, or Software Design if required
- Pass all unit and functional tests including regression tests on Travis or comparable CI framework
Create pull request for the feature branch
- Complete and mark off the submission checklist – include reports, documentation, tests, etc.
Code review of feature branch pull request
- Verify completion of pull request checklist by reviewer
- Perform minimum set of functional tests by two Beta sites
- Approve the pull request by at least two other reviewers – credential based on meritocracy
Commit feature branch
- Commit feature branch to the Master branch by one of the two designated repository administrators.
PopHealth versions are created for each minor and major releases. The releases are published on the Github site - https://github.com/OSEHRA/popHealth/releases. Release notes are published for each major releases. For minor release, a short description is provided to indicate the changes made for the minor release.