This project seeks to provide agencies responsibility for benefit eligibility determinations with an affordable platform to obtain the data they need. We want this platform:
- To show an applicant what data is being sent and get their explicit agreement
- Avoid storing any unnecessary information about particular applicants
- Integrate with existing workflows and infrastructures
- Do me last! Anything that’s a ‘proper noun’, similar to example here: https://dsacms.github.io/ospo-guide/resources/glossary/#custom-developed-code
- The open source offering consists of all necessary assets to build a docker image along with the necessary documentation
- Community scope will shift over time, and to begin, we will engage with the Emmy community to define the initial scope, and an expanded short and medium term scope that we are working towards.
- Community principles and processes can be found in our COMMUNITY.md file in the project repository.
See COMMUNITY.md
Nava describes the existing process here.
(We describe an ideal future state we would like to get to in the future, and point to a specific section CONTRIBUTING.md or other doc here, e.g. Release Format and Platform)
- Generally, Emmy strives to adhere to the CMS Open Source Release Guidance outlined here: https://dsacms.github.io/ospo-guide/outbound/release-guidelines/
- A git tag will be made for each release, the tag will be the version string prefixed with a ‘v’ (i.e. ‘vX.Y.Z’)
- Each git tag will also correspond to a github “release”: https://docs.github.com/en/repositories/releasing-projects-on-github/about-releases
- Pre-built docker images will be pushed to DockerHub for each release, tagged with the version string. Additionally, the ‘latest’ tag will be updated with each release and each major / minor versions will have tags corresponding to the most recent sub-version
- Releases will update the CHANGELOG.md file to appropriately describe important updates
Accessibility standards will follow the guidelines from USWDS: https://designsystem.digital.gov/ and adhere to specifications from GSA: https://www.gsa.gov/website-information/accessibility-statement, currently that means working with WCAG 2.1, but we will update versions as GSA does.
Section 508 Compliance 21st Century IDEA Act Compliance
We ensure that this platform supports switching between different locales, but only provide support for English and Spanish within this repository. We want to ensure that new languages can be added by anyone who wishes to extend the system by documenting the process.
As with other Tier3 Open Source Community Projects at HHS/CMS, Emmy is taking a 'co-planning' approach to do community-informed roadmapping.
The COMMUNITY.md file outlines how committer and maintainer privileges are distributed and managed.
DESIGN-PROPOSAL.md and ARCHITECTURE-PROPOSAL.md outline the process by which product and infrastructure suggestions are prioritized and decided.
TECHRADAR.md outlines the overall technology stack and tooling constraints that the project operates within, and the process by which new major technologies are introduced to the project.
CONTRIBUTING.md defines the context, conditions, and processes by which contributions to the project are made.
ISSUE_TEMPLATE*.md and PULL_REQUEST_TEMPLATE.md define the mechanics of how changes are proposed and merged.
Bug reports should be made through github issues using the Bug Report template.
Feature requests should be made through GitHub issues using the feature_request.md issue template.
We will create an email address to accept feedback from users. Additionally, feedback can be given through GitHub Issues.
Active work can be tracked by the public through repository issues and GitHub project boards. The project page will communicate planned milestones and labels on GitHub issues.
(define SLA for GitHub issues here) No user tech support