-
Notifications
You must be signed in to change notification settings - Fork 6
Home
This page outlines how maintenance, user support, and updates will work for the Certification Repository. Overall, responsibility for the Certification Repo and the site will lie with the CMS Product Owner - currently this is Nick Aretakis. The Product Owner will coordinate or delegate activities with the rest of the team.
We anticipate the following activities as part of maintaining the site:
- Receiving external questions and suggestions
- Adding and editing CMS outcome statements or support copy
- Adding entirely new pages or features
- Managing PRs + the main branch
- Managing the backlog
- Announcing changes
All inquires should come in through either the [email protected] mailbox or issue submissions via Github. Github issue submissions will be flagged for the triage-ers though email notifications.
If the triager can answer the inquiry themselves they are empowered to do so. The rest of the triage team will know that an inquiry has been answered by making sure the other triage-er is copied on the email.
In cases where more input is needed to respond or if the inquiry is an outcome statement sample that a State wants to submit for the site, the following paths will be taken:
- Outcome statement example submissions
- Loop in Product Owner + State's SO to review the submission
- If good, the one of the reviewers will create a PR for right business area for the submission
- The PR is reviewed by a CMS owner
- If more input is needed the CMS owner will work with the SO + the submitter to resolve
- The PO + States SO will coordinate communication to the state
- to let them know that it has been reviewed and is going to be added or
- to provide feedback on making the example better
- Typos, questions, general feedback, and feature requests
- The triager creates an issue in Github for tracking the work
- The triager is responsible for pulling in the parties needed to answer the question. The first stop should be the Product Owner who can help direct from there.
- If the triager can make the change, they can submit a PR with the change
- The PR is reviewed by a CMS owner
- If more input is needed the CMS owner will work with the SO + the submitter to resolve
All improvements should be documented as issues in Github via the backlog management process. We will utilize an issue template to make management easier.
As the CMS Product Owner prioritizes updates to outcomes statement or support copy, the following will happen:
- The work will be outlined in a Github issue and assigned to an editor/writer who will make the change - this could be a CMS team member or a partner
- The editor/writer will create a new branch and PR for the work
- Once ready for review, the editor/writer will submit the PR for review
- A CMS Owner will review the PR + add any feedback as needed
- Once ready for publishing, a CMS Owner will merge the changes to the staging (for preview) and main (for production) branches
The source data files in the /_data folder generate both the in-page outcome tables as well as the downloadable CSVs for each page. Filenames here are case-specific and whitespace-sensitive, so make sure to update all references to that table if you rename a file.
For example,
{% assign cms = "MES Outcomes - CMS-Required Claims Processing" %}
matches the file at
/_data/MES Outcomes - CMS-Required Claims Processing.csv
Ideas for new pages or features will be brought to the Product Owner and tracked in the Github backlog. The Product Owner will compare to the Certification Repo project brief to determine what is in scope for the current increment and responsible for prioritizing change for future increments.
The backlog will be tracked using issues in the repo's Github Project board. Anyone with can submit issues and they can be utilized to capture new feature ideas or enhancements, bug or typo fixes, and to track tasks. The repo will automatically provide an issue template and pull request template.
The Product Owner is responsible for managing the board. Reviews of the board should happen on a bi-weekly cadence. New issues are automatically added to the "Prioritized Backlog" column. The column will be maintained to show High-Priority issues at the top and Low-Priority issues at the bottom. As issues are worked on they manually need to be moved to the "In Progress" column. All issues in the "In Progress" column should be assigned to the person working the issue. If a PR is is needed to close the issue, the pull request template should be filled out including the issue number that the PR will close. By including the issue number (ex: #123) in the template, when the PR merged is close, Github will auto close the related issue.
While anyone can submit ideas, issues, or PRs only CMS Owners can merge to production. CMS Owners will be responsible for reviewing PRs, responding with any feedback that is needed, and merging to master.
CMS Owners include:
- Nick Aretakis (Primary)
- Jamie Miller (Backup)
- Eugene Gabriyelov (Backup)
- Kia Banton (Backup)
The "main" branch is the master branch to be displayed on GitHub Pages for production content. The "staging" branch is used for staging (work-in-progress) content.
- Any Github user can create and commit to a new branch
- CMS owners are the only users allowed to merge into "staging" or "main".
- PRs merging into "staging" or "main" will require at least one reviewer other before merging.
- Each merging PR should also include a content edit to the "Recent Updates" section of the homepage. These edits should include a list of the titles and hyperlinks of PRs being merged.
Please see the "Contributing" section of the project readme for more information: https://github.com/CMSgov/CMCS-DSG-DSS-Certification-Staging#contributing
Github allows us to work in the open, but it is important to manage noise for our users to make sure they are able to tell the things they need to pay attention to vs. changes that may have little impact for them. We will use two features on the repo to keep users up to date:
We will use the "Recent updates" section on the landing page to let users know about major changes or updates. This section will be manually updated by the Product Owner or other team member as needed.
For more detailed information users will be able to view release notes and a link to the project board from the roadmap page. These can be automated with either links to the notes/board in the GH backend or via embeds on the page.