> For the complete documentation index, see [llms.txt](https://policies.recaptime.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://policies.recaptime.dev/community/open-source/release-policy-and-checklist.md).

# Release policy and checklist

## To open-source or innersource?

By default, internal projects are considered innersource if the codebase/project sources are accessible only to the team; otherwise, they are open-source if a corresponding OSI-approved license is present.

Please note that if you proceed, our fiscal sponsor will hold the copyrights to your project on our behalf. Be sure to consider this when reviewing our licensing guidelines.

### Regarding GitLab for Open-source Program Terms compliance <a href="#gitlab-for-opensource" id="gitlab-for-opensource"></a>

Innersource projects that are private are considered ineligible for hosting on our GitLab SaaS namespaces. For compliance reasons, they should not be mirrored/hosted there unless manually cleared by Andrei Jiroh in coordination with GitLab's open-source program team. If you need to email them, remember to CC `~recaptime-dev/crew.recaptime.dev@lists.sr.ht` in your correspondence.

While we can have one private project for purposes of security or moderation decisions (we choose to operate the moderation project in hybrid mode, meaning issues may be confidential, but publish those reports and stats there), we may need clearance from GitLab's open-source program team first or use a separate namespace for that.

Alternatively, you can also host them at Tulir Asokan's Manimum GitLab instance under TBD.

## Contributions

All contributions to a Recap Time Squad-hosted project are made under the project license in an inbound-outbound model under [the Linux DCO](/community/open-source/linux-dco.md) to simplify copyright license compliance without doing the admin paperwork on both sides

## Checklist

* [ ] [Select an OSI-approved license](/community/open-source/licensing-guidelines.md)
* [ ] Adopt the [Code of Conduct](/community/code-of-conduct.md) and [Linux DCO](/community/open-source/linux-dco.md)
* [ ] Migrate any project-specific secrets from repository secrets settings to our centralized setup on Doppler or use `dotenvx` to manage encrypted secrets as part of Git history.
* [ ] Add contributing guidelines/documentation at `CONTRIBUTING.md`

## Notes

### Why do we call the GitLab.com instance GitLab SaaS? <a href="#gitlab-dotcom-vs-saas" id="gitlab-dotcom-vs-saas"></a>

We call the cloud-hosted GitLab.com instance GitLab SaaS to match the SaaS pricing, even though their handbook says otherwise.