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.
- Radicle Development Technical Principles
- Radicle Development Organizational Principles
- [PART 2] Radicle Development Work Criteria
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.
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.
- 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.
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.
- Core Teams should operate transparently and openly
- Contributing to Radicle should be as easy as contributing to an open-source project
- Are there other principles that are missing?
- Where/How else can these principles be applied?
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.
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.