These projects involve fundamental changes to the way CockroachDB works. What’s important to remember here is that supporting external development of these projects will take a non-trivial amount of time from the Cockroach team that would otherwise be spent building the product, so we really need to make sure it’s worth it. In practice, we’ve found even strong developers have little success with these types of projects and, in most cases, it is faster for our team to build these features ourselves.

That being said, if you’re up for the challenge there are a few prerequisites. You should:

1. Convince the CockroachDB team of your ability to drive a larger project. For this, you can either work with the CockroachDB team on mid-sized projects first, or provide some other evidence that you are an expert at building high quality distributed systems.
   Note: The engineering team may not support further exploration if they think the project is too complex for an external contributor or if we already have a schedule for this work and you cannot guarantee delivery on that schedule.
2. Make a high-level proposal for your project, declaring your intention, the area of functionality, and how much time (and, if applicable, people) you have available to work on the project. You should do this via a GitHub issue.
   Note: This review may take a few days to a few weeks, depending on our team’s availability and the complexity of the project.
3. Engineers and product managers will review your plans to understand how it fits into our roadmap from a technical and business point of view. This will inform how much support we will be able to provide.
4. Submit an RFC.
5. Engineers will review your RFC and discuss the detailed design from a technical perspective. This will further inform how much support we will be able to provide.
6. Once everyone is on the same page in terms of the design and impact, you can begin implementation with our support.
   Note: The CockroachDB team may have to pull a project back in house if development is happening too slowly or your team goes radio silent.

• Avoid submitting an RFC for a complex project before approaching the CockroachDB first with a high-level description. The risk is that you spend a lot of effort on writing a RFC and the CockroachDB team then decides the project doesn't fit on the roadmap.
• If you fork the CockroachDB repository and start working on a complex project in your fork without following the process above, chances are extremely slim that your functionality will eventually be merged in the main CockroachDB distribution. The reason for this is that we will not agree to merge any code changes that have not been validated step by step (i.e., commit by commit) in accordance with our quality standards, and we are not yet able to validate these quality standards on external repositories.

In situations where we will not be able to support your team through an implementation, we will do our best to communicate why we are making that decision.