[Org Design] Funding Core Teams: Principles & Criteria [Part 1]

🌱 About
1

Funding Core Teams: Principles & Criteria [Part 1]

Based on feedback from the workshops held during the Paris Contributor Offsite, we identified some consensus around a set of principles and criteria to use while onboarding, offboarding, refunding, and evaluating Core Team work.

We, the Org Design Working Group, decided to put forward a first draft of these principles and criteria for further discussion and formalization with Radicle contributors. The intention is to have these tools incorporated and even inform the next iteration of the MVDAO org design.

Contents

  • Radicle Development Technical Principles
  • Radicle Development Organizational Principles
  • [PART 2] Radicle Development Work Criteria

:mega: TL:DR; We’ll be discussing the proposed Technical Principles on a live call this Friday, August 19th at 12pm CET. We’d like to specifically encourage our technical contributors to participate in this discussion. For those who can’t make this time, please be sure to share your thoughts in this Discourse post — we will make sure they are included! The proposed Organizational Principles will be discussed next week.

Principles

Technical Principles

:seedling: This is a set of technical principles that can be applied to evaluate if Core Team work is value-aligned. These technical principles should be adopted and applied to Core team work at first (at the Radicle Development DAO level), and potentially could be mandated RadicleDAO-wide in the future.

The first attempt at defining these principles was made in the Towards Decentralized Code Collaboration blog post. They were chosen because they resemble values that we recognize as integral to free and open source code collaboration. We’ve included them here for reflection and deliberation:

  • It must prioritize user freedom.
    • In the words of the free software movement: […] users have the freedom to run, copy, distribute, study, change and improve the software. Thus, free software is a matter of liberty, not price.
  • It must be accessible and uncensorable.
    • Anyone should have the freedom to use the software to collaborate with others. No single party should be able to ban or restrict users from accessing the system, or content from being shared. Untakedownable.
  • It must be user-friendly.
    • The software must be easy to use and not expect tremendous change in behavior from the user. Responsiveness and functionality must meet the standards established by current platforms.
  • It must not compromise on security.
    • Trust in a third party or intermediary must not be required for use. Every artefact of the system must be attested with cryptographic signatures, and verified.
  • It must be offline-friendly.
    • It must not require internet connectivity, DNS or online portals to function. There must be no single point of failure and it must be always available.

:speech_balloon: Discussion Questions:

  • Are these principles still applicable? Can they effectively guide Core Team work moving forward post- transition?
  • Are there other principles that are missing?
  • Should these principles change over time? If so, when should they be evaluated?

Note: All principles might not apply explicitly to every piece of work. However, they can act as a guiding force to help resolve conflicts.

Organizational Principles

:seedling: This is a set of principles that — alongside the Radicle mission — helps define the MVDAO’s collective evolutionary purpose.

We tried to capture the consensus we identified at the offsite, compiling the team’s collective thinking into a set of principles representing the way we work (as in the Core Teams and their contributors) and our culture. We believe these principles can be used in the following ways:

  • Guide funding decisions/criteria evaluation for Radicle core development.
  • Influence organizational design
  • Refine mission/vision
  • Onboard contributors and define culture

Each principle is paired with “should” statements that can act as criteria/constraint for the next iterations of the organizational design.

  • Autonomous Agency & Self-Management
    • Core Teams should be shepherded as opposed to gatekept.
  • Optimistic Trust
    • Core Teams should be funded and coordinated optimistically.
  • Collective Responsibility
    • In a structure that requires emergent coordination, Core Teams should be responsible for holding each other accountable rather than relying on a hierarchy.
  • Open-Source
    • Core Teams should operate transparently and openly
    • Contributing to Radicle should be as easy as contributing to an open-source project

:speech_balloon: Discussion Questions:

  • Are there other principles that are missing?
  • Where/How else can these principles be applied?

Next Steps

We will discuss the Technical Principles on Friday, August 19th at 12pm CET. Next week, we will discuss the Organizational Principles and Work Criteria [another post to follow]. Add the call to your calendar here.

:mega: CALL TO ACTION: If you have opinions/thoughts on the Principles outlined above, please share them in this Discourse post by the end of the week and/or participate in the scheduled live discussions! We believe it’s necessary to define these principles together, so we encourage participation from our contributors.

8 Likes
2

Nice work! It’s really nice to see all the progress. :slight_smile:

Concerning technical principles, we recently did an exercise with some of the core engineers with regards to requirements for the radicle p2p protocol. I am only sharing in case some of those requirements are relevant for the technical principles section: Radicle Protocol Requirements - HackMD

3 Likes
3

Here’s my initial deliberation on the old bullet points :slight_smile:

“Untakedownable” and “uncesorable” seem like strong positions to take. I think this phrasing is more lightweight in comparison:

My thinking is that we allow the aforementioned “user freedom” to ignore/avoid anything that they may consider irrelevant, spammy, or illegal. I think the phrase “censorship resistant” fits that description better. When it comes to “untakedownable”, I wonder how this flies in the face of “right to forget” and GDPR compliance – a hard problem when it comes to peer-to-peer/federated networks :slight_smile:

Change in behaviour from what? :smile: Also, does this tenet not – potentially – inhibit innovation on our side creating a positive change in behaviour?

The part about “single point of failure” doesn’t quite fit with “offline-friendly”, in my eyes. Perhaps it might be better to change “offline-friendly” to “available”. I would say that encompasses a local-first experience while also stating that there are multiple points of entry for retrieving and pushing new data.

1 Like
4

Thanks for the writeup!

Some first thoughts. I’m not sure about some of the wording and tone. The technical principles especially seem both too ambiguous and too strong and, in a way, I’m not sure any of Radicle’s current projects truly fit them.

As an example:

To some extent, virtually everything we do requires trusting a third party. E.g. internally Radicle currently relies on: Discord, Telegram, Twitter, GitHub, Notion, Vercel, cloud hosting, domain name services, internet providers, USDC (and the US gov by proxy), fiat gateways, a small number of token holders, etc.

This rules out Drips, workstreams, and most of the code collab offering.

One suggestion might be to word these principles more as beliefs (i.e. guiding principles) rather than as an RFC style specification.

Something along the lines of:

  • User freedom — we believe in the principles of the free software movement — the users have the freedom to run, copy, distribute, study, change and improve the software
  • Trust-less — we believe in minimizing or eliminating our software’s reliance on trusted third parties.
  • Censorship-resistant — we believe in building systems that are censorship-resistant.
  • Local-first — we believe local-first architectures lead to a better user experience.

RFC language is designed to be unambiguous in order to succinctly communicate technical specifications that never change. That’s important for a technical specification, but it feels less appropriate here where we’re communicating ideas that are naturally more ambiguous (e.g. “user-friendly”, “trust-less”, etc) and where the tone should imply flexibility and have a feeling of being malleable.

I think the same thing applies to the organisational principles.

Shepherding feels like a bad metaphor here, as it refers to a shepherd (a single, absolute authority) controlling and guiding their sheep (low autonomy, low freedom) for economic value. This seems opposed to the principle of “Autonomous Agency & Self-Management”

5 Likes
5

Hi all!

After a very productive discussion, we have enough feedback to work on the second iteration of our Technical Principles. Thank you for everyone who joined & contributed, including @fintohaps @cloudhead @sebastinez @erikli @matto and others (I’m forgetting everyone who was there!)

:mega: CALL TO ACTION: Tomorrow, we will be discussing the proposed Organizational Principles at 4:30pm CET. Add the call to your calendar here.

From there, we will publish a second version of this post for final deliberation before we formalize it :slight_smile:

Thanks all! :seedling:

4 Likes