Release to open source: checklist

[brianamarie]

I'm going to share https://github.com/githubtraining/training-manual with the world. The following are items that we need to take care of to get this repository in shape for the open! @githubtraining/trainers, @beardofedu, @amyschoen, if you're able to help with any of these, that would be very helpful 🙇 (cc @matthewmccullough, @BonnieC)

Before we make this public, we need to complete the following:

Coordination

• The repo is visible to the teams below (typically all employees should have read access pre-open-source)
  • In progress: https://github.com/github/entitlements/pull/10424/
• Discuss with @github/legal if there are any licensing or other legal concerns.
  • In progress: https://github.com/github/open-source-releases/issues/120
• Discuss with @github/public-relations if it make sense to do any press around the release.
  • In progress: https://github.com/github/open-source-releases/issues/120
• Discuss with @github/marketing if it makes sense write about this project on the GitHub blog.
  • In progress: https://github.com/github/open-source-releases/issues/120
• Open an issue in github/creative to request a snazzy logo We have been using an image from the Octodex for this org and plan to continue with it

Preparation

• It has a name that is easy to remember, gives some idea what the project does, and does not conflict with an existing project or infringe on any trademarks.
• It uses consistent code conventions, clear function/method/variable names, and a sensible public API.
• The code is clearly commented, documenting intentions and edge cases.
• The distribution mechanism is as convenient, standard, and low-overhead as possible (RubyGems, Homebrew, Bower, Maven, NuGet, etc.).
• I have opened an issue in the oss-legal-review repo regarding how we use (or do not use) encryption in this repository. Please put a link to that issue in the comments on this issue.
  • In progress: https://github.com/github/oss-legal-review/issues/382
• There are no sensitive materials in the revision history, issues, or pull requests.
  • If any sensitive content or commit messages are found in commits, consider squashing the revision history.
  • If we wish to preserve sensitive history or we wish the public repo to have zero non-commit history, rename the private repo and create a new blank slate repo with the intended public name and any commit history intended to be public.
• It has a CONTRIBUTING.md based on this template.
  • In progress: Add a contributing guide #207
• opensource+REPO@github.com is provided as a maintainer contact (e.g., in the .gemspec email field for Ruby gems).
• It has a LICENSE; which one documented at licenses for GitHub open source projects.
  • In progress: Add a license #205
  • All dependencies (including transitive) are under compatible open source licenses (License Finder may be useful to do a spot check)
  • It is a library/will not be shipped as an application (eg desktop, mobile, or server package), or if it is, it is released with user-available license and credits information (desktop or mobile; see legal eagle) or includes license and credits information for a bill of materials (server; see licensed).
• It has a CODE_OF_CONDUCT.md; use http://contributor-covenant.org/version/1/4/code-of-conduct.md and fill in opensource@github.com as the email address.
  • In progress: Create CODE_OF_CONDUCT.md #206
• It has a SECURITY.md; use https://github.com/actions/.github/blob/master/SECURITY.md or equivalent for the org it is being released in.
  • In progress: Create SECURITY.md #210

README.md

• All in progress: Update README for open source #212
• It starts with a one-line description that explains what the project is about, who might be interested in it, what language its written in, and how it might be different from similar projects.
• It includes a list of features and limitations.
• It states the goals and scope of the project to help set expectations and filter proposed changes down the line.
• It includes the current status (e.g., proof of concept, used in production, active development, orphaned, etc.)
• It includes a description of the kind of environment required to run the software and instructions for setting it up.
• It clearly states the external dependencies and directions for installing them.
• It includes a high-level development roadmap or link to open issues/milestones.
• It explicitly asks for contributions, if you want them, with a link to CONTRIBUTING.md.
• It has a License section that states the license and if any GitHub logos are used, the line When using the GitHub logos, be sure to follow the [GitHub logo guidelines](https://github.com/logos).

Maintenance

• At least one Hubber is committed to managing community interactions by triaging and responding to issues, giving feedback and merging pull requests, and releasing new versions. This will be handled by the @githubtraining/programs team as a part of our existing comms duty.

Next steps

• Update the issue in the github/open-source-releases repository
• Make the repository public
• Change the name of the repository to github-training-manual
• Change the owner to github
• Implement redirection solution (create training-manual repository that links via README.md and gh-pages to the new manual?)
• Change the name

[parkerbxyz]

The repo is visible to the teams below (typically all employees should have read access pre-open-source) ❓ I have asked internally how to handle this because it is in a separate org

This would likely be handled via entitlements. Let me know if there's anything I can do to help!

[brianamarie]

Entitlements PR open here: https://github.com/github/entitlements/pull/10424

[parkerbxyz]

@brianamarie you mentioned the possibility of moving this repo from the githubtraining organization to the github organization during the Developer Training session of the Alpha Bootcamp. Is that still being considered?

Something else I think we should consider is renaming this repo to something more in line with how we name other similar repos (like admin-training) to make it more clear that this is the manual for developer training. I would propose changing the name to developer-training but I’m open to other ideas. 💡

[brianamarie]

@brianamarie you mentioned the possibility of moving this repo from the githubtraining organization to the github organization during the Developer Training session of the Alpha Bootcamp. Is that still being considered?

Something else I think we should consider is renaming this repo to something more in line with how we name other similar repos (like admin-training) to make it more clear that this is the manual for developer training. I would propose changing the name to developer-training but I’m open to other ideas. 💡

@parkerbxyz Thank you for bringing these up. I'm going to open a separate issue:👀#209

[brianamarie]

We're making huge progress and getting very close on this! Thank you all, especially @parkerbxyz and @amyschoen, for your contributions ✨

Outstanding items before moving to the formal open source release issue:

• Finalize name, and make any changes associated with that decision
  • Inform all folks delivering training so they can find the manual
  • Move and rename repository
  • Update readme and other supporting docs
  • Update internal links in the PS catalog
• Merge updated README
• Confirmation from oss-legal team (but that can be done in the formal open source release issue

🎉

[crichID]

@brianamarie I was playing around in the InnerSource course yesterday and found another thing we'll want to do before toggling this to OSS. The InnerSource course asks the user to click a link to this repo and asks if they can see it.

[brianamarie]

Hello folks 👋 We're VERY close to open sourcing the manual.

@githubtraining/implementation-engineers, Important information - Unless there is objection, I will plan to make the repository public on Friday, August 14th.

Other changes, like the rename and redirects, will happen later, on a day which we still need to coordinate. But, those changes will happen swiftly enough so that classes should not be interrupted because of the redirects. You can see those tasks, and other associated tasks, in the project board here.