Dogfooding radicle

[juliendonck]

With dogfooding of radicle we're looking to showcase how an open source project can replace the existing web2 code collaboration stack with a decentralized alternative. How it can leverage the new primitives that radicle introduces to create a more sovereign, sustainable and transparent collaboration stack.

Below I've tried to outline some key features I feel we need to successfully compete with what's the norm today. This is by no means an exhaustive list, but rather a base to start the conversation from.

Explore

• Search for projects 🐶
• Explore projects in your network

Code hosting

• Navigate to a project
• Look at the code ✅ 🐶
• See activity

code collaboration

• Creating & closing issues 🐶
• Creating & merging pr’s 🐶
• CI

Code conversations

• Discussions on issues and pr's
• linking to comments

Orgs

• Mulitple code owners ✅🐶
• Checkpointing releases ✅
• Code accessible to all org members (org node)

Porting

• back up to radicle 🐶
• Export to radicle

Legend: ✅ = in the app 🐶 = critical for dogfooding

[juliendonck]

@geigerzaehler @rudolfs @brandonhaslegs here's the first draft, quote sections and comment away 🐗

[geigerzaehler]

I think the list is quite exhaustive and there’s only one feature missing (multiple project maintainers, more on that below).

To come up with priorities for dogfooding I thought about where I spend most of my time on Github. That’s creating and reviewing PRs. This includes commenting and checking CI status. So for me the top priorities would be

• Creating & merging pr’s
• Discussions on prs
• Very basic CI integration

The CI integration can be as simple as showing the status for a commit that is fetched from a remote URL, nothing fancy.

Since I expect discussions to be quite some work we will also need to think about an intermediate workaround where we can do the discussions on a different platform.

If we implement this, then we can move the first pieces of our workflow to Radicle.

On thing that makes patches (this is what we’re calling PRs) in a P2P model different from PRs and more difficult to implement is that there is no canonical source for the code. The idea of the protocol is that the newest commit that all maintainers agree on is the reference commit for the project. This means that patches would need to be accepted be all maintainers. This feature of having multiple maintainers on a project is not implement yet in Upstream. Only the primitives are available from the protocol and this hasn’t been tested yet. (Nor do I have a good grasp on who this works conceptually.)

[rudolfs]

Good points @geigerzaehler, especially the one about multiple maintainers on the p2p side! I'd prioritise the features the same way.

Another thing that I'm thinking of, is discoverability of new peers of a certain project. For example, I create a project and publish it and then somebody follows it and creates a patch. Unless I now add them explicitly to my peer list, I don't see their changes. But to add them I first need to know somehow what their Device ID is and that they have published something. Maybe that's already captured by "See activity" or "Explore projects in your network"?

[rudolfs]

We're already dogfooding: https://app.radicle.network/seeds/maple.radicle.garden/rad:git:hnrk8ueib11sen1g9n1xbt71qdns9n4gipw1o/tree/83ef38568ecc8d073ad57d824072f8552fd673b8.