bancolombia/oss-enterprise

Bancolombia Open Source Office guides.

oss-enterprise's Issues

Release bancolombia/commons-jms

I'm going to share commons-jms with the world, but before I do, I want to make sure:

Coordination

• The repo is visible to the teams below
• Discuss licensing or other legal concerns with legal team @mention (when it applies)
• Evaluate security concerns with security team @mention
• Request a snazzy logo from creative team @mention
• Discuss promotion strategy with communications team @mention and marketing @mention

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
• The repository description includes a link to the project homepage (when it applies)
• It uses consistent code conventions and clear function/method/variable names
• The code is clearly commented, documenting intentions and edge cases.
• The distribution mechanism is as convenient, standard, and low-overhead as possible (Homebrew, Bower, Maven, NuGet, etc.).
• There are no sensitive materials in the revision history, issues, or pull requests.
• Code coverage is greater than 80%
• It uses publicly-accessible continuous integration that integrates with the GitHub status API.
• correct email is provided as a maintainer contact
• It includes the correct LICENSE according to license policy
• It has a CODE_OF_CONDUCT.md created using this guide (https://docs.github.com/es/communities/setting-up-your-project-for-healthy-contributions/adding-a-code-of-conduct-to-your-project)
• It has a CONTRIBUTING.md based on the template in this repository.
• A project homepage has been created that includes (when it applies)
  • A reference implementation
  • End user documentation

README.md

• 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 with a link to CONTRIBUTING.md.
• It has a License section that states the license.

Preparing to Maintain

• At least one internal employee is committed to managing community interactions by triaging and responding to issues, giving feedback and merging pull requests
• The process for releasing a new version is clearly documented
• At least two internal employees have access to release new versions
• At least one internal employee is committed to pulling each release into other internal products that depend on this project

Publish the code!

• Ask the open source office to make the repository public
• Communicate the release internally
• Launch external marketing efforts