Microsoft Open Source release checklist

[alexcnichols]

Preparation

• [ ] Successfully completed a release registration and review.
• [ ] Completed an Intellectual Property (IP) scan of the code to be released, if required.
• [x] The project uses consistent code conventions, clear function/method/variable names, and a sensible public API.
• [x] The code is clearly commented, documenting intentions and edge cases.
• [x] The project 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.
• [x] The distribution mechanism is as convenient, standard, and low-overhead as possible (RubyGems, Homebrew, Bower, Maven, NuGet, and so on.)
• [x] At least two team members have access to release new versions.
• [x] The process for releasing a new version is clearly documented.
• [ ] There are no sensitive materials in the commit history, issues, or pull requests.
• [ ] The project uses publicly-accessible continuous integration that integrates with the status API.
• [x] The process for contributing is clearly documented in the README.md or CONTRIBUTING.md.
• [ ] All licensing and legal concerns have been addressed.
• [x] Has LICENSE file(s) in the approved format.

README.md

• [x] Starts with a one-line description that explains what the project is about, who might be interested in it, what language it is written in, and how it might be different from similar projects.
• [x] Includes a list of features and limitations.
• [x] States the goals and scope of the project to help set expectations and filter proposed changes down the line.
• [x] Includes the current status (for example, proof of concept, used in production, active development, orphaned, and so on.)
• [x] Includes a description of the kind of environment required to run the software and instructions for setting it up.
• [x] Includes a link to the Microsoft Open Source Code of Conduct. See How does a project adopt the code and process? for details.
• [x] Clearly states the external dependencies and directions for installing them.
• [x] Includes a high-level development roadmap or link to open issues/milestones.
• [x] Explicitly asks for contributions, if you want them, with information on how to contribute and/or a link to a CONTRIBUTING.md file.
• [x] Includes a pointer to where questions should be asked and how the development team can be contacted.
• [x] Includes information on how to privately report security vulnerabilities (to MSRC).

Ship it

• [ ] Double check/confirm that all sensitive material has been removed from commit history, issues, and pull requests.
• [ ] Make the repository public.
• [ ] Tweet about it from your personal account.
• [ ] If it makes sense, blog about this project.

Going forward

• [ ] At least one team member is committed to managing community interactions by triaging and responding to issues, giving feedback, merging pull requests, and releasing new versions.
• [ ] At least one team member is committed to pulling each release into our products that depend on this project.

[alexcnichols]

@cschleiden / @danhellem - did one of you go through the release registration process to get the repo created? That should tell us whether we're good with any legal concerns.

[alexcnichols]

We're clean on the PoliCheck test I just ran.