Publishing Your Project: Step 2. Getting Approval

The Power Software Development Review Team (SDRT) is here to help developers at Power prepare code for external publication, promote projects, and build open source communities. Our process is designed to set your project up for success, and to comply with relevant company policies. In Step 1, we show you how to prepare your project to request SDRT approval. This page highlights the questions we will review with you to secure an approval for your publication request.

Prepare Your Project Information

Include the answers to the following questions into a ticket assigned to the SDRT.

1. Provide a repo link for the project you want to publish.
2. Provide us (or link to) open source dependencies (and their licenses).
3. What is the business value to Power for publishing this code? (related: Why did you write this code in the first place? At that time, did you plan that you’ll be publishing it as an open source project?)
4. Was all the code in this project authored by a Power employee? If not, please elaborate.
5. Does your team agree this project should be published?
6. Where is this code used in production? (If this code is not in production, why not?)
7. Has your team allocated time to support this code once it’s published?
8. Have you prepared the code according to the process detailed on the Publish page?
9. Do you need any apps or webhooks enabled for the repo, such as CI?
10. Have you prepared a communications plan (e.g. blog post, meetup presentation) announcing this project?
11. Have you performed a security scan or review of your repo? Provide details of how.

Review and Discussion

Depending on the nature of your project and the responses to the questions above, we’ll discuss any issues we find with your code publication. First we’ll want to understand why you seek to publish this code and what you seek to gain from it. We seek to publish projects that add distinct value to the open source community, that solve problems that have not been solved before, that address needs that other people will also have, and that will attract positive attention to our development work. We avoid publishing projects that we don’t actually use in production (if we can’t convince our co-workers to use this code, why would we convince people who don’t work with us all the time to use this code?). We avoid publishing code that solves a problem that has already been solved by an active open source community. We’d rather contribute to an existing effort if possible.

We want to make sure that relevant senior developers are aware of open source publications before they are published. They often have valuable insight to contribute that is better to include into the process before we publish code. It’s not easy to redact code once published, so let’s take time to make sure we publish properly. We’re not looking for perfect code (after all, we’re going to invite people to give us bug fixes and suggestions). We’re looking to make sure we don’t regret the publication. We’re also looking to avoid creating projects that never get any uptake or attention.

Some projects are very straightforward and we’ll approve them quickly. Our diligence is not intended to be a barrier, but a service. We want to help you ensure that you have everything ready for launching your new project.

Process

Once you have SDRT approval, proceed to release your project. You can go back and review the prepare your request step, or return to the Publishing Overview.