IV CBV Payroll is supported by a dedicated team of individuals fulfilling various roles to ensure its success, security, and alignment with government standards and agency goals.
| Role | Name | Affiliation |
|---|---|---|
| Product Manager | Ming Ligh | CMS |
| Product Manager | Jacob Worrell | CMS |
| Designer | Seth Owings | CMS |
| Software Engineer | Jake Shilling | CMS |
| Software Engineer | Imhotep Benjamin | CMS |
| Software Engineer | Jan | CMS |
| Contracting Officer's Representative | Mark DeZalia | CMS |
| Product Manager | Allyse Parekh | CMS |
| Designer | Paul Gehrig | Nava |
| Software Engineer | Tom Dooner | Nava |
| Software Engineer | Daphne Gold | Nava |
| Software Engineer | Tim Miller | Nava |
| Software Engineer | Ben Calegari | Nava |
| Open Source Lead/Community Manager | Nočnica Mellifera | Nava |
See CODEOWNERS for a list of those responsible for the code and documentation in this repository.
See Community Guidelines on principles and guidelines for participating in this open source project.
- @tdooner (Tom Dooner)
- @daphnegold (Daphne Gold)
- @millerti (Tim Miller)
- @bencalegari (Ben Calegari)
- @j-shilling (Jake Shilling)
- @imhben (Imhotep Benjamin)
- @dx-gov (Jan)
- @tdooner (Tom Dooner)
- @daphnegold (Daphne Gold)
- @millerti (Tim Miller)
- @bencalegari (Ben Calegari)
- @j-shilling (Jake Shilling)
- @imhben (Imhotep Benjamin)
- @dx-gov (Jan)
We'd like to acknowledge the following individuals for their past contributions of this project:
- @pperozo (Patricia Perozo)
- @YvetteWhiteUSDS (Yvette White)
- @allthesignals (Matt Gardner)
- @GeorgeCodes19 (George Byers)
- @jeffcatania-usds (Jeff Catania)
- @iannorriswork (Ian Norris)
- @patsier-cms (Pat Sier)
- @clediggins-usds (Cle' Diggins)
- @acouch (Aaron Couch)
- @JosephGasiorekUSDS (Joseph Gasiorek)
The members of IV CBV Payroll community are responsible for guiding its development, ensuring quality standards, and fostering a collaborative environment. They play a vital role in making decisions about code contributions, handling releases, and ensuring the project meets its goals and objectives. Below is a list of the key members and their specific roles and responsibilities. We are eagerly seeking individuals who are interested in joining the community and helping shape and support these roles.
| Roles | Responsibilities | Requirements | Access Privileges |
|---|---|---|---|
| Contributor | Active contributor in the community | Multiple contributions to the project | • Assigned issues • Granted access to running CI/CD commands • Added in repository domain teams |
| Maintainer | Set direction and priorities for a sub-project | • Experience as a reviewer for 3 months • Demonstrated responsibility and excellent technical judgement for project |
• Approves PRs to all areas of project • Official Project Representative • Has a vote in decision-making meetings |
| Alumni | None, IV CBV Payroll thank the alumni for their service | • Must have been an active contributor or maintainer |
• Assigned issues • Granted access to running CI/CD commands • Added in repository domain teams |
Description: A Contributor contributes directly to the project and adds value to it. Contributions need not be code. People at the Contributor level may be new contributors, or they may only contribute occasionally.
- Following the project CoC.
- Following the project contributing guidelines in CONTRIBUTING.md.
- Report and resolve issues.
- Submit and review PRs.
- Contribute to the documentation.
- Participate in community discussions.
- Answer questions from other community members.
- Test releases and submit reviews.
- Run or help run events.
- Promote the project in public in line with the COMMUNICATIONS.md policy.
- Help maintain the project and community infrastructure.
- Invitations to contributor events.
- Access to community spaces and infrastructure.
- Eligible to advance along the project's CONTRIBUTOR_LADDER.md.
- Other privileges defined by the community in the future.
Description: Maintainers are established contributors who are responsible for entire areas of the project. As such, they have the ability to approve PRs against specific areas of the project, and are expected to participate in reviewing and approving contributions to the project.
A Maintainer must meet the responsibilities and requirements of a contributor, plus:
- Reviewing at least 2 PRs per 3 months, especially PRs that involve specific parts of the project.
- Mentoring new contributors.
- Writing and refactoring submitted PRs.
- Participating in Emmy maintainer activities.
- Proposing contributions to strategy and policy of the project.
- Participating in, and leading, community discussions.
- Mentoring other Maintainers.
- Exercising judgment for the good of the project, independent of their employer, friends, or team, in line with project GOVERNANCE.
- Become responsible for a key project management area as indicated in CODEOWNERS.
- Must be actively contributing for at least 3 months to at least one project area:
- Authored 2 merged PRs
- Reviewed 2 PRs
- Resolved 2 Issues
- Can commit to reviewing a minimum of 4 PRs per 3 month cycle.
- Can commit to contributing at least 2 PRs per 3 month cycle, as demonstrated by https://github.com/DSACMS/iv-cbv-payroll/graphs/contributors.
- Approve PRs to their specific domain of the project.
- Represent the project in public as a Maintainer in line with the COMMUNICATIONS.md policy.
- Communicate with the Emmy team on behalf of the project.
- Other privileges defined by the community in the future.
- Any current contributor may become a new Maintainer, by meeting the requirements, and opening a PR against the root of the iv-cbv-payroll adding the themselves as a maintainer in the COMMUNITY.md file and corresponding team in the CODEOWNERS file.
- At least 2 current Maintainers from the Core Team must then approve the PR.
Members of the Core Team are federal employees or contractors who contribute to this project as part of their formal work duties. They serve as the main point of contact for development activity in the repository and have the same privileges and responsibilities as maintainers and codeowners.
This document contains principles and guidelines for participating in the IV CBV Payroll open source community.
These principles guide our data, product, and process decisions, architecture, and approach.
- Open means transparent and participatory.
- We take a modular and modern approach to software development. Adopters of Emmy should be able to adopt the full experience with UI, or just an API component.
- We build open-source software and open-source process.
- We value ease of implementation.
- Fostering community includes building capacity and making our software and processes accessible to participants with diverse backgrounds and skillsets.
- Data (and data science) is as important as software and process. We build open data sets where possible.
- We strive for transparency for algorithms and places we might be introducing bias.
All community members are expected to adhere to our Code of Conduct.
Information on contributing to this repository is available in our Contributing file.
When participating in Emmy open source community conversations and spaces, we ask individuals to follow the following guidelines:
- When joining a conversation for the first time, please introduce yourself by providing a brief intro that includes:
- your related organization (if applicable)
- your superpower, and how you hope to use it for IV CBV Payroll
- Embrace a culture of learning, and educate each other. We are all entering this conversation from different starting points and with different backgrounds. There are no dumb questions.
- Take space and give space. We strive to create an equitable environment in which all are welcome and able to participate. We hope individuals feel comfortable voicing their opinions and providing contributions and will do our best to recognize and make space for individuals who may be struggling to find space here. Likewise, we expect individuals to recognize when they are taking up significant space and take a step back to allow room for others.
- Be respectful.
- Default to positive. Assume others' contributions are legitimate and valuable and that they are made with good intention.
It is important for contributors to be and stay active to set an example and show commitment to the project. Inactivity may lead to unexpected delays, contributor attrition, and a lost of trust in the project.
- Inactivity is measured by:
- Periods of no contributions for longer than 6 months.
- Periods of no communication for longer than 6 months.
- Consequences of being inactive include:
- Transfer to Alumni status
Involuntary removal/demotion of a contributor happens when responsibilities and requirements aren't being met. This may include repeated patterns of inactivity, extended periods of inactivity, a period of failing to meet the requirements of your role, and/or a violation of the Code of Conduct. This process is important because it protects the community and its deliverables while also opening up opportunities for new contributors to step in.
Involuntary removal or demotion is handled through maintainers filing an issue using the contributor_ladder.md template, and sending a PR to the COMMUNITY.md file.
If and when maintainers' and contributors' commitment levels change, contributors can file an issue using the contributor_ladder.md template, and send a PR to the COMMUNITY.md file indicating their updated status.
The Community Guidelines sections were originally forked from the United States Digital Service Justice40 open source repository, and we would like to acknowledge and thank the community for their contributions.