This Request for Proposals (RfP) intends to **invite applications** for new [Radicle Grants](https://radicle.mirror.xyz/7RDTvdxABVndpZge9VT09Ku5JXD8lCCCpLRRZaVrtJU) that will flesh out **integrations** of the Radicle Decentralized Code Collaboration tools **with the most prominent CI servers / services**.

## Motivation (Why)

As has been already discussed in several forums / channels (e.g. [1](https://radicle.zulipchat.com/#narrow/stream/369277-heartwood/topic/integration.20with.20CI.20servers/near/362291203)) , one of the main onboarding hurdles for developer teams to move to Radicle will be their automation and Continuous Integration / Continuous Delivery (CI/CD) pipelines that they have hooked into their existing repositories.

There are a number of reasons why the migration from their existing CI/CD system would present a problem:

### Problem 1: Unwanted Migration

Maintainers might already be happy (or simply satisfied) with their existing CI system and not in search of a solution that addresses new problems. "If it works, don't change it" is a common saying in software and with a million other problems to solve, feature backlogs that never get smaller and communities constantly requesting new features / bug fixes, migrating across CI servers is rarely a priority for open source maintainers.

### Problem 2: Learning Curve

Maintainers might not want to invest the time to learn about a new CI system. Any new system or technology requires a time investment to get acquainted with. We are already asking folks to migrate from a centralized forge to a peer-to-peer forge and there is already a new workflow to get used to with that migration alone.

In order to try to minimize the learning effort required, we should allow open source maintainers to keep their existing CI system. One less thing to worry about for them - one less hurdle for Radicle onboarding.

### Problem 3: Financially Unsustainable

Several open source projects have found a way to run their CI compute workload with no charge (i.e. without having to pay a cost for it). This is either through some direct sponsorship (e.g. through a Foundation), or through one of the "Free for Open Source" plans that are offered by several hosted CI providers. Moving to a new CI system would only be an option in the case where they can have corresponding "free" minutes for their CI compute.

### Problem 4: All-in-one migration vs. Multiple Smaller Migrations

Moving away from GitHub/GitLab and other forges presents a **huge overall challenge**. In addition to the *migration of the **code*** (which is a git repository and therefore rather trivial to migrate), and the *migration of the **CI/CD pipeline*** (which we are discussing in this doc), there are also separate data/process migrations to be considered, e.g. for the case of GitHub:
- issues
- pull requests / merge requests
- wiki
- forum
- artifact repository (releases)
- social features (stars, activity, achievements, etc.)
- sponsors
- security features (e.g. dependabot)

Each of these requires individual consideration with regards to how the maintainers could maintain history and data continuity and, in some cases, the move to Radicle Code Collaboration may not (yet) provide an alternative.

With all the above points in mind, there is a pretty compelling case in favour of allowing maintainers to keep their existing CI solution when migrating to Radicle.

The migration to a decentralized CI should be considered **independently** of the migration to a decentralized code collaboration tool.

## Scope (What)

### Current State

At the time of writing, no Continuous Integration / Continuous Delivery (CI/CD) integration functionality exists in *Heartwood* (the current iteration of the Radicle protocol).

A small team has recently been onboarded to tackle the missing CI features. This team aims to tackle the following 2 focus areas:

* in the short-mid term: enabling **integrations with existing CI servers** and incorporating CI check results in Radicle `Patches`,
* in the longer term: work on a **new decentralized CI solution** with the ambitious goal of a new paradigm for distributing the CI compute workload and establishing a new model around CI.

### Goal of this RfP

The goal of this RfP is to fund the integration efforts with the most popular/used CI/CD systems. It is not currently within the scope of the Radicle core team to take on the implementation and maintenance of all these integrations, so we are looking for others who care about *decentralized code collaboration* to help us build those up.

This RfP intends to help fund the **initial** development versions of the tooling required for the most popular CI servers. It is limited in scope in the following ways:

* it is not intended as a long-term funding vessel (successful projects could "graduate" into using other long-term funding options),
* it is not intended to cover every possible integration - we will focus on the most popular ones,
* focus should stay on Developer eXperience (DX) and not on features.

### Integration Architecture

At the time of writing, the CI team is working on [a prototype](https://app.radicle.xyz/seeds/radicle.yorgos.net.gr/rad:zBNXLtTqUu9LBZHCPFShAeXnp5Gz/patches/cc6074a631f600fc27dd021a7248494fa7a2f1af) of a new component of the Heartwood stack that will form the basis of integration for external CI systems.

This new component is a *broker* (`radicle-ci-broker` 😉 ) and it will be responsible for the following jobs:

* **relay events** from the radicle node to the CI server, so that various jobs can be triggered.
* **monitor** CI job runs and
* **update the corresponding radicle entities** (e.g. `Patches`, `Commits`, etc.) with the result of the CI job run, so that maintainers can know if their change is breaking anything.

We will update this post with more information about the broker, but, in lack thereof, please reach out to `@yorgos` on the [Radicle Community Chat tool](https://radicle.zulipchat.com/) to find out more details.

## Audience (Whom)

We invite *any* and *all* developers that:

* have experience with specific Open Source CI/CD servers,
* have experience with popular Hosted CI/CD solutions,
* care about decentralization,
* love writing Free/Libre and/or Open Source Software (FLOSS)!

Join us on our journey away from proprietary platforms and help us build **a better home for one of the world's most important public goods: Open Source Software**.

## How to Submit (How)

* Put together a team (can also be just yourself!)
* Pick up the [template](https://github.com/radicle-foundation/radicle-grants/blob/main/rfps/template.md)
* Start writing a grant application for the `v0.1` of your particular integration.
* smaller grants are preferred, especially for new teams
* subsequent grants are an option
* focus on breaking the work down into sizeable/estimatable tasks.
* avoid too much implementation detail.