bancolombia/oss-enterprise

Bancolombia Open Source Office guides.

Releasing Open Source

Do you want to release something as open source? Awesome! It's up to you to get it ready, but don't worry, you are never alone. You can read the checklist and then open a new issue to get started. Consider these questions as you start to open source the project.

What should be open source?

It's easier to answer this question in terms of what should not be open sourced:

1. Don't open source anything that represents core business value. If it makes us lots of money by being closed source, don't open source it.
2. Don't open source anything that is specific to internal processes. If it won't be useful to anyone that doesn't work here, don't open source it.
3. Don't open source anything you can't commit to maintaining long-term. Some projects are inherently difficult to maintain. If you don't want to spend time accepting contributions and working with the open source community, don't open source it.

Open Source Maintainer Expectations

Before you open source your project, consider the effort required to maintain it. Being an great open source maintainer requires more effort than managing a closed source project. Read our Maintainer Guide to understand what will be expected of you.

What should I keep in mind before using open source?

Before using a source project in your project, consider evaluating the criteria to keep in mind and best practices. Thus, you will avoid uncomfortable surprises later. Read our Using OSS Guide

Communication Guidelines

When interacting in a repository owned by the Bancolombia organization, you are speaking on behalf of the company. Read our Communication Guidelines

Blog

We've an engineering blog where we're publishing three posts every month about how we do technology at Bancolombia. You can read it on https://medium.com/bancolombia-tech

Do you work for Bancolombia? You can write your own posts. Contact the open source office through Microsoft teams for the process.

FAQ

Who owns the code I contribute to open source projects?

Work in progress! 👷‍♂️ 👷‍♂️ 👷‍♀️ 👷‍♀️

License

This repository is licensed under CC-BY-4.0 (c) 2019 GitHub, Inc.

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