start

Signed-off-by: Adam Gutglick <adam@spiraldb.com>

Author: AdamGS

rfcs/0061-ci-2-0.md

@@ -6,7 +6,46 @@
 
 ## Summary
 
-## Motivation
+This RFC intends to propose a cohesive architecture for the project's CI and workflow system. There have been many conversations (both public and private) on this topic,
+and I would like to try and propose a holistic vision that can be discussed and iterated in a public forum.
+
+## Current state
+
+The current solution includes (but is not limited) to CI, publishing and benchmarking. It is fully implemented using Github Actions workflows and apps, and relies on
+a mix [runs-on](https://runs-on.com/) powered self-hosted runners and GitHub hosted runners.
+
+### Infrastructure
+
+Our self-hosted runners use a custom AMI, that we build using a private repo only accessible to members of the GitHub organization.
+
+### Permissions
+
+There are four different scopes of permissions:
+
+1. Admins - very limited group of users that can manage the organization-wide settings, and the core repo settings.
+2. Maintainers - All TSC members, can push branches and open pull requests directly from within the core repo, and approve and merge pull requests.
+   CI runs automatically for them, and they can trigger CI for external contributions.
+3. Members - Non-TSC members that are explicitly trusted. They have the same development experience a maintainer has, aside from the ability to approve and merge pull requests.
+4. Everyone else - have to open PRs using a fork in a classic GH flow. Requires a maintainer to run any actions-based workflow, label their PR etc.
+
+### Benchmarking
+
+TODO
+
+### Testing and CI
+
+TODO
+
+### Versioning and publishing
+
+Every pull request must include a label indicating the sort of change it includes (feature, fix, chore, performance, ci or skip).
+Those changes are accumulated into a draft release. What that draft is published, a workflow is triggers that gradually publishes all rust crates
+and all language or framework bindings in order. Those include:
+
+1. Rust crates (including integrations like `vortex-datafusion`).
+2. Python package
+3. JNI bindings
+4. Spark bindings
 
 ## Design