{"id":18793080,"url":"https://github.com/dsacms/repo-scaffolder","last_synced_at":"2025-09-13T07:15:16.919Z","repository":{"id":199745038,"uuid":"701006332","full_name":"DSACMS/repo-scaffolder","owner":"DSACMS","description":"Templates and commandline tools for creating repositories for US Federal open source projects ","archived":false,"fork":false,"pushed_at":"2025-08-22T20:08:41.000Z","size":9600,"stargazers_count":33,"open_issues_count":37,"forks_count":16,"subscribers_count":3,"default_branch":"main","last_synced_at":"2025-08-22T22:46:56.182Z","etag":null,"topics":["cmsoss-tier3","cookiecutter-template","maturity-models","repo-hygiene","repolinter"],"latest_commit_sha":null,"homepage":"https://dsacms.github.io/repo-scaffolder/","language":"HTML","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"cc0-1.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/DSACMS.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":"CODE_OF_CONDUCT.md","threat_model":null,"audit":null,"citation":null,"codeowners":"CODEOWNERS.md","security":"SECURITY.md","support":null,"governance":"GOVERNANCE.md","roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2023-10-05T18:06:51.000Z","updated_at":"2025-08-22T20:08:14.000Z","dependencies_parsed_at":"2023-12-21T19:52:50.142Z","dependency_job_id":"c7c34397-cc94-4045-b191-1209ababdebc","html_url":"https://github.com/DSACMS/repo-scaffolder","commit_stats":null,"previous_names":["dsacms/repo-scaffolder"],"tags_count":1,"template":false,"template_full_name":null,"purl":"pkg:github/DSACMS/repo-scaffolder","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/DSACMS%2Frepo-scaffolder","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/DSACMS%2Frepo-scaffolder/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/DSACMS%2Frepo-scaffolder/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/DSACMS%2Frepo-scaffolder/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/DSACMS","download_url":"https://codeload.github.com/DSACMS/repo-scaffolder/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/DSACMS%2Frepo-scaffolder/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":274932112,"owners_count":25376076,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","status":"online","status_checked_at":"2025-09-13T02:00:10.085Z","response_time":70,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["cmsoss-tier3","cookiecutter-template","maturity-models","repo-hygiene","repolinter"],"created_at":"2024-11-07T21:23:27.214Z","updated_at":"2025-09-13T07:15:16.909Z","avatar_url":"https://github.com/DSACMS.png","language":"HTML","funding_links":[],"categories":[],"sub_categories":[],"readme":"# repo-scaffolder\n\nTemplates and commandline tools for creating repositories for US Federal open source projects\n\n## About the Project\n\nThe CMS Open Source Program Office developed a [maturity model framework](https://github.com/DSACMS/repo-scaffolder/blob/main/maturity-model-tiers.md) to classify federal open source projects based on their maturity level. Each tier outlines specific files and content that are required or recommended to be included in the repository.\n\nThe repo-scaffolder project creates repositories that adhere to open source hygiene standards and best practices. It provides templates and guidance for project metadata, contributing practices, community governance, feedback mechanisms, security policies, and more. Using [cookiecutter](https://github.com/cookiecutter/cookiecutter), repo-scaffolder helps teams identify what tier their project is classified as and fill in project information to be inputted into the file templates. In turn, this provides the project sufficient structure and foundation to promote a healthy open source ecosystem\n\nThis repository also includes [outbound checklists](#Outbound-Checklists) for each tier outlining the review process for releasing repositories as open source.\n\nFor existing repositories, repolinter via GitHub Actions is used to identify any files and information missing from the repository according to their maturity tier.\n\n\u003c!-- TODO: Include more information on outbound checklists --\u003e\n\n\u003c!---\n### Project Vision\n**{project vision}** --\u003e\n\n\u003c!--\n### Project Mission\n**{project mission}** --\u003e\n\n\u003c!--\n### Agency Mission\nTODO: Good to include since this is an agency-led project --\u003e\n\n\u003c!--\n### Team Mission\nTODO: Good to include since this is an agency-led project --\u003e\n\n## Core Team\n\nA list of core team members responsible for the code and documentation in this repository can be found in [COMMUNITY.md](COMMUNITY.md).\n\n## Repository Structure\n\n##### Usage\n\n- [Using repo-scaffolder](#Using-repo-scaffolder)\n- [Updating repositories using GitHub Actions](#Updating-projects-with-new-repo-scaffolder-upstream-file-changes)\n- [Documentation](./docs)\n\n##### Maturity Models\n\n- [Maturity Model Framework](./maturity-model-tiers.md)\n- [Tier 0](./tier0/README.md)\n- [Tier 1](./tier1/README.md)\n- [Tier 2](./tier2/README.md)\n- [Tier 3](./tier3/README.md)\n- [Tier 4](./tier4/README.md)\n\n##### Outbound Checklists\n\n- [Tier 1](./tier1/checklist.md)\n- [Tier 2](./tier2/checklist.md)\n- [Tier 3](./tier3/checklist.md)\n- [Tier 4](./tier4/checklist.md)\n\n##### Files\n\n- [CONTRIBUTING.md](./CONTRIBUTING.md)\n- [COMMUNITY.md](./COMMUNITY.md)\n- [CODEOWNERS.md](./CODEOWNERS.md)\n- [COMMUNITY_GUIDELINES.md](./COMMUNITY_GUIDELINES.md)\n- [CODE_OF_CONDUCT.md](./CODE_OF_CONDUCT.md)\n- [SECURITY.md](./SECURITY.md)\n- [LICENSE](./LICENSE)\n\n## Using repo-scaffolder\n\n### Create a new repository using repo-scaffolder\n\nThe Open Source Program Office follows a maturity model framework to classify federal repositories according to their level of maturity: https://github.com/DSACMS/repo-scaffolder/blob/main/maturity-model-tiers.md.\n\nThere are 4 tiers in the maturity model framework. The `/tier*` directory consists of templates, files, and scripts for each respective tier:\n\n- `{{cookiecutter.project_slug}}` is the directory containing templates and files to be generated upon repository creation. This serves as your repository starting point.\n- `cookiecutter.json` defining the questions cookiecutter asks.\n- `hooks`, a folder containing scripts to be run upon repository creation.\n- `checklist.md` \u0026 `checklist.pdf` is the outbound review checklist with guidelines on releasing the repository as open source.\n- `README.md` with more information about the maturity tier and file contents.\n\n#### Prerequisites\n\n- python\n- github cli\n- [cookiecutter](https://github.com/cookiecutter/cookiecutter)\n- [repolinter](https://github.com/todogroup/repolinter)\n\n##### Installation (On Mac)\n\n```\npython3 -m venv venv\n. venv/bin/activate\npip install -r requirements.txt\nbrew install gh\n```\n\n#### Need help picking a maturity tier?\n\nIf you do not know what tier your project is, the `tier-determiner.py` script will walk you through questions to figure out what tier you need. Run:\n\n```\npython tier-determiner.py\n```\n\nYou can also follow the flowchart below to determine your project's tier.\n![Tier Selection Flowchart](./assets/images/flowchart.png)\n\n#### Know what maturity tier you need?\n\nIf you know what tier you need, you can run the cookiecutter for an individual tier. Use the below command with `X` substituted for the tier number.\n\n```\ncookiecutter https://github.com/DSACMS/repo-scaffolder --directory=tierX\n```\n\n### Update an existing repository using repo-scaffolder\n\nYou can update existing projects with repo-scaffolder. Using the `-s` flag on cookiecutter will not overwrite existing files. Follow these steps:\n\n1. Create a new branch in your repo\n2. cd into folder above\n3. run: `cookiecutter -f -s https://github.com/DSACMS/repo-scaffolder --directory=tierX`\n4. Make sure when answering the questions you use the existing folder/project name\n5. Raise pr into main\n\n### Metadata collection using code.json\n\n\u003c!-- TODO: Add text here about code.json and link code.json docs --\u003e\n\n#### Add code.json to your project\n\nEach repository should contain a code.json file with metadata about the project.\n\nTo add code.json into your project, navigate to your project's `.github` directory and run the following cookiecutter command. You will be asked questions about the project (see cookiecutter.json) in order to collect and store this metadata in code.json.\n\n```\ncookiecutter . --directory=codejson\n```\n\n### Maintaining your repository using repo-scaffolder\n\n#### Updating repository using GitHub action workflows\n\nThe OSPO created various [GitHub Action workflows](../docs/workflows.md) that can be used to regularly update your repository. The jobs are located in `.github` directory of your project.\n\n#### Updating projects with new repo-scaffolder upstream file changes\n\nWhen creating projects, if you want to receive updates then add `dsacms-tierX` as a github topic to the repo. The scaffolder repo includes github workflows that will find all repos with that tag and can raise a pull request with an updated string or adding a file. See [actions.md](https://github.com/DSACMS/repo-scaffolder/blob/main/.github/actions.md) for more information.\n\n### Identify missing files and information using repolinter\n\nRepolinter is a tool maintained by the [TODOGroup](https://todogroup.org/) for checking repositories for common open source issues, using pre-defined rulesets. This can be run stand-alone as a script, pre-commit in your IDE, or post-commit or within CI/CD systems!\n\n✔    =  Pass\n\n✖    =  Fail\n\n⚠  =  Warn\n\nTiers of level 0 thru 4 have repolinter.json file in their projects. Tier0 has detailed configuration of all the rules. All the other tiers extends their previous tiers and has only the `rule` and the `level` configuration.\n\nSample commands to run with the given repolinter.json path:\n\n```\nrepolinter lint . # Runs on target directory\n\nrepolinter lint . --config path/to/repolinter.json # Use if the repolinter config is not in the root dir\n\n```\n\n#### Automated repolinter actions\n\nA tool to automatically update repositories up to hygenic standards with the use of [Repolinter through GitHub Actions](https://github.com/DSACMS/repolinter-actions) is also available. This action sends a PR to your repository with templates of all the missing files and sections that are required using a predefined rulset. Visit the repository for more information on how to get this action up and running.\n\n#### Automated Releases and Guidelines\n\nThis tool automatically generates release guidelines and automated workflows that generate changelogs based on the standards that are set within those guidelines.\n\nFor instance, semantic versioning is expected and required for the baseline changelog workflow to work in your newly generated project.\n\nMore information on release guidelines can be found [here](./release-guidelines-template.md)\n\n# Development and Software Delivery Lifecycle\n\nThe following guide is for members of the project team who have access to the repository as well as code contributors. The main difference between internal and external contributions is that external contributors will need to fork the project and will not be able to merge their own pull requests. For more information on contributing, see: [CONTRIBUTING.md](./CONTRIBUTING.md).\n\n## Local Development\n\nThis project contains several different features.\n\n- `/tier*` contains file templates for repository creation and metadata collection using cookiecutter. Refer to the README.mds to learn more about the file contents.\n- `/.github` contains GitHub actions to update repositories contents across the ecosystem.\n- `checklist.md` \u0026 `checklist.pdf` is the outbound review checklist with guidelines on releasing the repository as open source.\n- `maturity-model-tiers.md` \u0026 `maturity-model-tiers.pdf` contain information about our maturity model framework.\n\n### Editing/adding tiers and template contents in repo-scaffolder\n\nAt a top level, each tier consists of a folder for `hooks`, a folder containing the files to be added (`{{cookiecutter.project_slug}}`), and a `cookiecutter.json` defining the questions cookiecutter asks. These naming conventions must be followed as that is what cookiecutter picks up. The `hooks` folder needs to be duplicated in each tier. The folder containing the files to be added can include slugged out variables such as `{{ cookiecutter.project_name }}` that can be filled in by the answers to `cookiecutter.json`.\nFor example, `{{ cookiecutter.project_name }}` will be filled in by this question - `\"project_name\": \"My Project\",`.\n\nSee the [cookiecutter docs](https://cookiecutter.readthedocs.io/en/stable/)\nfor more information.\n\n\u003c!-- TODO: Add guidance on updating repolinter --\u003e\n\n## Coding Style and Linters\n\n\u003c!-- TODO - Add the repo's linting and code style guidelines --\u003e\n\nEach application has its own linting and testing guidelines. Lint and code tests are run on each commit, so linters and tests should be run locally before commiting.\n\n## Branching Model\n\nThis project follows [trunk-based development](https://trunkbaseddevelopment.com/), which means:\n\n- Make small changes in [short-lived feature branches](https://trunkbaseddevelopment.com/short-lived-feature-branches/) and merge to `dev` frequently.\n- Be open to submitting multiple small pull requests for a single ticket (i.e. reference the same ticket across multiple pull requests).\n- Treat each change you merge to `dev` as immediately deployable to production. Do not merge changes that depend on subsequent changes you plan to make, even if you plan to make those changes shortly.\n- Ticket any unfinished or partially finished work.\n- Tests should be written for changes introduced, and adhere to the text percentage threshold determined by the project.\n\nThis project uses **continuous deployment** using [Github Actions](https://github.com/features/actions) which is configured in the [./github/workflows](.github/workflows) directory.\n\nPull-requests are merged to `dev` and the changes are immediately deployed to the development environment. Releases are created to push changes to production in the `main` branch.\n\n## Contributing\n\nThank you for considering contributing to an Open Source project of the US Government! For more information about our contribution guidelines, see [CONTRIBUTING.md](CONTRIBUTING.md).\n\n## Community\n\nThe repo-scaffolder team is taking a community-first and open source approach to the product development of this tool. We believe government software should be made in the open and be built and licensed such that anyone can download the code, run it themselves without paying money to third parties or using proprietary software, and use it as they will.\n\nWe know that we can learn from a wide variety of communities, including those who will use or will be impacted by the tool, who are experts in technology, or who have experience with similar technologies deployed in other spaces. We are dedicated to creating forums for continuous conversation and feedback to help shape the design and development of the tool.\n\nWe also recognize capacity building as a key part of involving a diverse open source community. We are doing our best to use accessible language, provide technical and process documents, and offer support to community members with a wide variety of backgrounds and skillsets.\n\n### Community Guidelines\n\nPrinciples and guidelines for participating in our open source community are can be found in [COMMUNITY.md](COMMUNITY.md). Please read them before joining or starting a conversation in this repo or one of the channels listed below. All community members and participants are expected to adhere to the community guidelines and code of conduct when participating in community spaces including: code repositories, communication channels and venues, and events.\n\n## Feedback\n\nIf you have ideas for how we can improve or add to our capacity building efforts and methods for welcoming people into our community, please let us know at opensource@cms.hhs.gov. If you would like to comment on the tool itself, please let us know by filing an **issue on our GitHub repository.**\n\n## Acknowlegements\n\nThis project was developed as a collaboration between the United States Digital\nService ([USDS.gov](https://usds.gov)), The Department of Health and Human\nServices ([HHS.gov](https://hhs.gov)), The Digital Service at the Centers for\nMedicare \u0026 Medicaid Services ([CMS.gov](https://cms.gov)) and The\n[USDigitalResponse.org](https://usdigitalresponse.org).\n\n## Policies\n\n### Open Source Policy\n\nWe adhere to the [CMS Open Source\nPolicy](https://github.com/CMSGov/cms-open-source-policy). If you have any\nquestions, just [shoot us an email](mailto:opensource@cms.hhs.gov).\n\n### Security and Responsible Disclosure Policy\n\n_Submit a vulnerability:_ Vulnerability reports can be submitted through [Bugcrowd](https://bugcrowd.com/cms-vdp). Reports may be submitted anonymously. If you share contact information, we will acknowledge receipt of your report within 3 business days.\n\nFor more information about our Security, Vulnerability, and Responsible Disclosure Policies, see [SECURITY.md](SECURITY.md).\n\n### Software Bill of Materials (SBOM)\n\nA Software Bill of Materials (SBOM) is a formal record containing the details and supply chain relationships of various components used in building software.\n\nIn the spirit of [Executive Order 14028 - Improving the Nation’s Cyber Security](https://www.gsa.gov/technology/it-contract-vehicles-and-purchasing-programs/information-technology-category/it-security/executive-order-14028), a SBOM for this repository is provided here: https://github.com/DSACMS/repo-scaffolder/network/dependencies.\n\nFor more information and resources about SBOMs, visit: https://www.cisa.gov/sbom.\n\n## Public domain\n\nThis project is in the public domain within the United States, and copyright\nand related rights in the work worldwide are waived through the [CC0 1.0\nUniversal public domain\ndedication](https://creativecommons.org/publicdomain/zero/1.0/) as indicated in [LICENSE](LICENSE).\n\nAll contributions to this project will be released under the CC0 dedication. By\nsubmitting a pull request or issue, you are agreeing to comply with this waiver\nof copyright interest.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdsacms%2Frepo-scaffolder","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fdsacms%2Frepo-scaffolder","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdsacms%2Frepo-scaffolder/lists"}