# Roadmap v1.0

## Protocol

* October
* Fetch v2 - in the review phase. Done by Fintan, reviewed by cloudhead.
* NAT-traversal - in review phase. Done by Andrew Cann, review by cloudhead and Fintan.
* Fetch signed refs announcements - Fintan will be working on it. Assumed time: 1.5 weeks.

- November
* Cache for COBs. Arastoo is working on it, it will be reviewed by cloudhead.
* ls-refs for rad sync - Fintan will be working on it. Assumed time: 2 weeks.

- December

- 15th January - v1.0 release

Misc notes for Protocol domain: cloudhead, Fintan and Andrew Cann are full time on it and Arastoo is part time. Andrew Cann is currently out of the office.

Breaking the protocol into smaller parts to have a representation of how it looks:\

* Networking
* Connectivity (stable, features missing) - cloudhead
* Gossip (unstable, depending on NAT-traversal) - cloudhead
* Subscription
* NAT-traversal (waiting review) - andrew
* Peer discovery (mostly ready for v1.0) - cloudhead
* Framing protocol (stable) - cloudhead
* Replication
* Fetch logic (waiting review) - fintan
* Storage layout (stable) - cloudhead
* COBs
* Issues (stable, easy to extend) - cloudhead
* Patches (stable) - cloudhead
* History storage (finalizing the format of the cob manifest) - cloudhead
* Cache (missing implementation, might not be part of v1.0) - arastoo
* Identities (Repository)
* Delegation (stable, missing features) - cloudhead
* Private/Public (stable) - cloudhead

## Radicle CI and third-party CI integrations

Native CI:
- October
* CI COB - WIP, likely done by the end of the month. Being worked on by Lars, he will collaborate with Yorgos and Nikos.

- November
* Event handling mechanism for CI - worked on by Lars in close cooperation with Yorgos and Nikos.

- December
* Basic native CI - Lars will be working on this.

Third-party integrations (should be all done by v1.0):

* Milestone 1: Required Functionality on Radicle side
* Milestone 2: Woodpecker Integration
* Milestone 3: Kraken CI Integration
* Milestone 4: GitHub Actions Integration

For the third-party integrations, follow the link for a more detailed plan: https://community.radworks.org/t/radicle-ci-integrations/3394

Misc for CI team: Lars is full time, Yorgos and Nikos are working via Radworks grants. PoC for Concourse third-party integration is in place.

## Web UI/Interface

- Pre-release I (up to 23rd October):
* 2 column layout
* Track project
* Show what node a user is browsing
* Issue functions I.
* Show if the node is running
* Resizable input text fields
* Attachment interaction improvements
* Mobile view
* Sticky file headers in Patch/Changes
* Make entire copiable div clickable - rudolfs

- V1.0 (from 23rd October to 15th January):
* Auto sync issues once created
* Copy link to where you're at
* Patch functions I
* Patch functions II
* Reactive UI
* Issue functions II
* Changelog
* Mention users by did or alias
* Improve radicle.xyz
* Hints & Help
* Limit focus to repo
* File tree for revisions nav
* Add auth-only features on read-only view
* Patch functions III

Misc notes for Web/Interface team: Rudolfs is full time and Daniel, teramfo, Sebastian are part time. Thomas is also helping.

More about their roadmap currently at https://www.notion.so/radicle-web/94dc6935469e42648f9a5617d6e9681a?v=31416959d97a4c14877d9423a3ce5570

## Radicle CLI

The following is the layout of the CLI but currently no planned roadmap around it as it is evolving. Cloudhead is the main developer of the CLI.

* patches
* review (needs work by xla)
* open (git)
* `rad patch open`
* merge (git)
* `rad patch merge`
* update (git)
* `rad patch update`
* label (?)
* assign (?)
* comment (?)
* issues (needs some UX work)
* label
* assign
* comment
* identity (WIP)
* edit (needs work)
* delegate (needs work)
* propose (needs work)
* repos (most are in good shape but some need some work)
* list
* init
* inspect
* checkout
* clone
* fork
* remove
* track
* remotes
* sync
* auth (stable)
* self
* node (stable)
* start/stop
* status

## Radicle TUI

The large, monolithic TUI application will be broken up into smaller binaries that will integrate well with the CLI.

We'll start with an issue and a patch selector TUI. Both are supposed to be called from and call back the CLI, e.g. `rad patch show` would show the selector which will call `rad patch show <id>` with the selected patch.

### Scope

* general
* modularize architecture
* support for CLI <-> TUI calls
* support for TUI <-> TUI calls
* revisit UI design (improve visual integration with CLI)
* issues
* selector
* patches
* selector

### Timeline

* November
* modularize architecture
* patch selector
* December
* patch selector, issue selector
* January
* revisit UI design

## Docs

On the docs side it is the entire Radicle team. Stellarmagnet is helping with principles doc, personas (targeted audience depending on the story, release phase and features), user friendly getting started doc, etc. Lars is working on the architecture doc. We will likely turn team repo into a private one so we can collaborate on the documentation there and also hold internal documentation there (such as developer best practices guide etc).

Layout overview:

* man pages
* rad (getting started)
* rad-patch (contributor/maintainer flows)
* ?
* contributing.md (ok)
* hacking.md (ok)
* architecture.md doc (lars, wip)
* rips (1, 2, 3)
* seed node setup guide (?)
* marketing/brand material
* UI/UX guidelines
* Dev feature guide (internal)

Most if not all should be done by 15th January.

## Radicle blog

We plan to start Radicle blog and the current plan is (it might change):

* 1st post: architecture.md repurposed
* 2nd post: seed node setup guide
* 3rd post: nat hole punching
* 4th post: v1.0 release

## Misc news for the team

We would like to come into a habit of a release cadence of 6 weeks, and have iteration(s) meeting every 2-3 week to better handle the development workflow (developer best practices guide should help with this).

Yorgos might work on project management tooling on the Web UI frontend, Zlatan might work on project of project management tooling inside CLI. Both would likely happen via Radworks grants if approved.

Teams and individuals are encouraged to collaborate more in the open in Zulip, organize meetings to speed up the discourse and development where it is needed, self assess their timeline of work (how much will they spend on individual issue and in what order are going issues to be tackled). Please open an issue for all relevant tasks (and subtasks) so that issues can trace patches that are fixing them.

FOSDEM and CCC (TBA) are likely bigger events that we will attend in coming months.