[Discussion] Core Dev Org Proposal

louiegrey · January 9, 2023, 4:25am

The CDO WG will present this model in an all-hands on January 9th, 2023.

This proposal from the Core Dev WG presents an organizational model for the Core Development Org (CDO). The role of the Core Development Org is to support and fund core development of the Radicle project. This Org will replace the role of the Foundation in funding & coordinating the work of Radicle’s Core Teams.

Purpose

Maintain and develop the Radicle stack
Drive adoption of Radicle technologies
Support the development of the Radicle community

Principles/Values:

[Org Design] Funding Core Teams: Principles & Criteria [v2]

Scope and Function

Maintain core development vision, objectives, and technical philosophies
Onboard and offboard Core Teams
Collect, review, prioritize, and distribute budget of Core Teams
Create (funding and technical) proposals for submission to RadicleDAO

Design Process: Results of Design Sprint

Our design sprint resulted in three different models: Distributed Council (Flat), Distributed Council (Advisory), Distributed Groups. The first two prototypes played on the current organizational model of the Radicle Foundation, where the Foundation Council funds & coordinates all Radicle core development. The Flat version re-envisioned the Council to be made up of a representative from each Core Team. The Advisory version was the same, but included a third-party advisor that could act on behalf of the Core Teams within the Council. The Groups model split vision, planning/coordination, and execution among three separate groups. It also included a “voice” mechanism for Core Teams via a Veto Council composed of a representative from each Core Team.

For more details on the prototypes, check out this Figma (and see Highlights from Contributor Feedback)

Proposed Org Design

The proposed Org Design is a combination of the Distributed Council and Distributed Groups prototypes. It maintains the trusted “Council” approach — meaning, a few individuals are entrusted to make strategic decisions for the whole, but introduces a mechanism of “voice” from Core Teams to ensure contributors have a way to check the power of those in charge. The org design is composed of 4 stakeholders.

Steering Committee
Core Teams
Core Team Council
Internal Governance Facilitator

Steering Committee

In our proposed model, the Steering Committee is the governing power of the Core Development Org. It manages the vision, coordination, and budgeting of the Core Teams.

Steering Committee Responsibilities Overview

List of Responsibilities

Set and maintain yearly CDO Vision & Objectives, prioritize cross-team work, and coordinate roadmaps
Review & approve CT objectives (yearly)
Review & approve CT budgets (yearly)
Process CT budget increase requests (quarterly)
Create and submit org proposals to the RadicleDAO
Choose methods for measuring CT progress (e.g. health checks)
Define what constitutes a “Core Team”

Actions

Set yearly CDO vision and objectives
Onboard/offboard a Core Team
Add/remove a Steering Committee Member

Steering Committee Details

Steering Committee Members: The Members of the Steering Committee are selected by Core Team contributors. They are composed of any CDO Contributor. We propose that the size of the Committee should be capped at five people to ensure ease of coordination and distribution of workload. We also propose that the Foundation Council & Core Dev Org WG chooses the first set of Members, but any contributor can nominate an individual for consideration (See Steering Committee Member Elections). After the CDO is launched, Core Teams can move to add/remove Steering Committee Members via Core Team Council (See Core Team Council). Steering Committee Members are compensated.
Multisig: Steering Committee Members are signers on the CDO’s multisig. This multisig manages the operational budgets of the Core Teams. It is governed by a 2/3 super-majority policy.
Budgets: On an annual basis, the Steering Committee submits a funding proposal to the RadicleDAO that includes the estimated yearly budgets of the Core Teams. Once passed, the funding is distributed to the CDO’s multisig. If additional budget is required by the CDO throughout the year, the Steering Committee can submit an Additional Budget Request to the DAO.

Core Team Council

The Core Team Council is an ad-hoc decision-making entity that can be called by Core Team Contributors. It acts as a collective “voice” mechanism for CDO contributors to check the power of the Steering Committee.

The Council is composed of one representative from each Core Team. Core Teams choose their representation at their own discretion, but the collective Council can vote to remove a Core Team Rep. Council Reps are not compensated.

The Council is only called to vote when a Core Team contributor requests to:

Add/remove a Steering Committee member
Challenge a Steering Committee action (e.g. onboarding/offboarding a Core Team, setting yearly CDO objectives)
Add/remove a Core Team Council Rep

Add/Remove a Steering Committee Member

The composition of the CDO’s Steering Committee is formally governed by its contributors. This ensures the Steering Committee always acts in the best interest of the CDO’s contributors. A petition to add/remove a Steering Committee member can be made at any time but must include effective reasoning for the proposed change.

Challenge a Steering Committee Action

The Council can challenge a Steering Committee action. A challenge is a way for CDO contributors to formally counter a Steering Committee action. The Steering Committee still retains the right of final decision, but challenging an action is the way contributors can formally voice their opinion for the Steering Committee’s consideration. In this light, a petition (See Petition) to challenge a Steering Committee action must include a revised action(s) for the Steering Committee to take. If passed, the Steering Committee is expected to conduct a formal review of the petition, and present a revised plan of action. The final process for challenging SC decisions (e.g. windows and timeframes, challenging limits) still needs to be discussed. If you have ideas of input, please feel free to share.

Add/Remove a Core Team Council Rep

While Core Teams are able to choose their Rep on their own accord, the collective Core Team Council is able to add/remove a Rep on the Org’s behalf. This is to ensure that the Council best represents the collective of CDO Contributors. A petition to add/remove a Core Team Rep must include effective reasoning for the proposed change.

“Voicing” via Core Team Council

A request is made by any Core Team Contributor publishing a petition on community.radworks.org. Petitions must meet certain criteria to be considered. These criteria are defined and evaluated by the Internal Governance Facilitator (see Internal Governance Facilitator). Once a petition has been published, the Internal Governance Facilitator convenes the Council for a Snapshot vote. The action passes if 2/3 super-majority is reached.

Internal Governance Facilitator

To ensure that governance processes within the CDO are conducted fairly, the Org employs an Internal Governance Facilitator. This facilitator manages the internal governance of the Org by facilitating voting cycles, creating governance templates (e.g. petitions, challenges), creating conflict moderation processes as a neutral “third party”, and determining the process of onboarding/offboarding Org-level roles. The facilitator is a part-time role, and is a secondary role that any Core Team contributor can hold — similar to a Steering Committee Member role. The Internal Governance Facilitator can’t be a Steering Committee Member or Core Team Council Rep, but they are a signer on the multisig of the Steering Committee so they can initiate actions such as adding/removing a Member on behalf of both the Steering Committee and Core Team Council. Internal Governance Facilitators are compensated.

Call to Action for Feedback (by Jan. 20th)

The CDO WG will present this model in an all-hands on January 9th, 2023. CDO Contributors can provide feedback in any or all of the following forms:

During the presentation, we’ll be using Slido for anon questions (or contributors can ask openly/in chat).
For the next two weeks (until Jan. 20th), we will be offering office hours (1:1 time to go through the structure or any questions). DM louiegrey#0425 on Discord to schedule.
Leave comments on this forum post.

Appendix

Bird’s Eye View

Highlights from Contributor Feedback

These three models were presented to core contributors who offered feedback (thank you to @efstajas , @fintohaps , @cloudhead , @rudolfs , @Kaidao , @ange , and @sebastinez !). A few insights emerged:

The simplicity of the Flat and Advisory resonated the most among contributors and there was a general interest in the Group’s Veto Council as a voice mechanism for the Core Teams.
There was a desire for contributors to voice in the overall vision that’s set annually.
Contributors valued minimal governance processes, meaning minimizing new roles & additional approvals as necessary.
There was a call for an agile and iterative org structure that supports where Radicle is today, but can grow as Radicle grows.
Most had a positive reaction to a creation of an Ops Team.
There were voiced concerns over the workload of members of the Council in all models.

Steering Committee Member Elections

We are proposing the following initial election process for the Steering Committee:

The Core Dev Org WG and current Foundation Council will nominate the initial set of Steering Committee Members. Their nominations will be posted publicly on this community.radworks.org forum.
Following this post, there will be a one-week nomination period where any CDO Contributor (inside the org) can nominate themselves or others on the post. If someone is nominated, the nominee must publicly state on the forum post that they accept the nomination for running.
After the end of the nomination period (one week), there will be a Snapshot vote open to all Core Team contributors, using Otterspace badges. (1 badge = 1 vote).

After the Steering Committee is launched, Core Team contributors can add/remove Steering Committee members by petitioning the Core Team Council (see Add/Remove a Core Team Council. Finer details of this process are still being discussed and open for feedback.

Petitions

Petitions are used to Challenge a Steering Committee Action or Add/Remove Steering Committee Members/Core Team Council Reps. The Internal Governance Facilitator will maintain a petition template as a consistent manner to deliver feedback, while ensuring its contents meet communication requirements.

The initial suggested petition utilizes the COIN Framework, which structures feedback in the following:

Context: The circumstances, event or issue to discuss.
Observations: Specific, actual and neutral descriptions of actions.
Impact: How the event or issue affects others in the organization.
Next Steps: Suggested changes or improvements to move forward.

If you have additional questions or comments, please leave them below. We’re looking forward to your thoughts!

Core Development Org WG

shelb_ee · January 13, 2023, 11:36am

All-Hands Q&A

Below is a collection of the questions that came up in the All Hands call hosted for core contributors on Monday. I am posting them here for added context as folks review & digest the proposal.

We have picked out a few specific open questions that we would like your feedback on at the top. The Q&A in the second half of the post include some direct answers to clarifying questions from the presented model.

INPUT WE NEED FROM YOU!

If someone is removed from the Steering Committee, should that a “perma-ban”? Can they be added back at some point in the future (or immediately)? Furhtermore: What behaviors would permit a permanent ban? What behaviors/metrics would reinstate a Member? (see Organizational principles from former WG research for guidance)
Should the scope of the Internal Governance Facilitator’s role include conflict management? Is there anything else you think the IGF role should be or not include?
With that in mind, who do you imagine holding the IGF role?
1. Existing CDO Contributors who are on Core Teams that we believe still act neutrally in conflict
2. Contributors not in Core Teams or not engaged in Core Team activity (ie. Operations, someone in a different Org within the DAO - someone like Shelby or bordum)
3. Someone outside of the DAO
4. Other?
Should the roles of Steering Committee Member, Core Team Council Rep & IGF have regular elections vs operating on “optimistic” terms. If yes, what would be the right cadence for elections? Would CDO Contributors be open to voting for elections quarterly or annually or some other cadence?
Is anonymous voting (with Otterspace badges within the CDO) something that we should explore more deeply as an option for contributors while setting up voting systems?
Should we set up a more formal process for accepting anons into trust roles within the Org (i.e. Steering Committee Member, Core Team Council Rep & IGF)?

Q&A From Call

Steering Committee

How does the Steering Committee work? Does it also have an opaque process like the Foundation does today? Will it organize freely like a Core Team?

Answer: The Steering Committee organizes autonomously like a Core Team to fulfill their quarterly and annual responsibilities. While the proposal does not define how they should work or how opaque they need to be in the process (public meetings, quarterly report, etc), it defines the set of accountable outcomes that must be public and transparent – “Actions” (Annual vision/objectives, onboarding/offboarding Core Teams, Add/Removing a Steering Committee Member). Thoughts are welcomed. The WG will work with the initial set of Steering Committee Members to set best practices.
Who are the Steering Committee Members anticipated to be, if they’re not the Core Team Leads?

Answer: While the CDO WG and Foundation Council will nominate an initial set of Steering Committee Members, there will be an open nomination process where any CDO Contributor can self-nominate or nominate others. We anticipate Members with diverse skillsets to fulfill the Steering Committee responsibilities. The final Committee Members are elected through a voting process involving all CDO Contributors. While Core Team Leads could also theoretically be a Steering Committee Member, they can’t hold another role (such as a Core Team Council Rep or Internal Governance Facilitator).

Core Team Council

Is the Core Team Council all “soft governance”? Is there a formal/blockchain component where they can interact with the Steering Committee multsig? It would be nice to see the technical underpinnings of relationship between Council & Steering committee.

Answer: This concern is based on this element of the proposed design: “The Steering Committee still retains the right of final decision, but challenging an action is the way contributors can formally voice their revisions for the Steering Committee’s consideration. The Steering Committee is expected to incorporate revised actions from revision proposals.”

While the Core Team Council can petition revisions through formally challenging
the Steering Committee’s actions, the Core Team Council has absolute power in adding/removing a Steering Committee Member. This provides an incentive for the SC members to take revision proposals into account or risk being voted off of the SC.

How this would look “under the hood” has a few possibilities. The first would be to set up a Zodiac Reality mod that would, in the case of an off-chain Otterspace badge vote, execute an on-chain action on the SC multi-sig for the case of adding/removing SC members. Another option would be to give the Internal Governance Facilitator, Operations team or possibly the DAO token holders special permissions that override SC multisig signer.

Internal Governance

Can there be anonymous ways of posting petitions (to challenge Steering Committee decisions)?

Answer: While technically posting on the forum can be anonymous, we are hoping to use Otterspace badge as a reputation mechanism to check posts are from a valid contributor within CDO without needed to reveal their identity. We will look into more mechanisms.
Is there any periodic renewal of the Int. Gov Facilitator? Or are the Committees and the Facilitator set until a change is requested?

Answer: While the default at the moment is set at an “optimistic” process where individuals hold the position as long as they don’t get removed by the Core Team Council or want to leave the role, election cycles for the Internal Governance Facilitator (as well as the Steering Committee members) are very much open for discussion. While setting election cycles (quarterly/annually) to keep elected roles in regular check, they require contributor governance interaction through voting.
Is Otterspace still working on anon voting (with badges)?

Answer: They are planning on exploring private badges using zk technology, but that wouldn’t technically make the vote anonymous if its on-chain. Snapshot is has anonymous “shielded voting” off chain.

Roles/Process

Does “onboard CT” mean “hiring a new Core Team member”? What entity will make decisions about hiring?

Answer: Onboarding a CT (Core Team) is referring to the creation and funding of a new Core Team alongside the existing Core Teams (Clients, Funding, Marketing, Community) based on the needs of the CDO. Hiring individual contributors on each Core Team will be primarily left up to the Core Teams themselves. This will be partially checked by the Steering Committee during quarterly Core Team check-ins and budget reviews. At the moment, the administrative process in hiring (contract, payment, resources, etc. setup) is a responsibility held by the Core Teams, but could possibly be handed over through the creation of a Core Team.
For example, if Core Teams want to create a “Talent Team,” to handle the recruiting and administrative process of hiring, that suggestion can come up in the quarterly check-ins with the Steering Committee. Any contributors can suggest a Talent team, who will have to post a proposal to the Org and the Steering Committee will review the proposal to decide to onboard and fund that team or not based on their deliverables.
Can members of any of these teams be anons? Or do they all have to have at least some sort of team-public identity?

Answer: We do not foresee issues with anons holding any of the roles discussed here. We already have a few anon contributors within the CDO and bordumb as the Grants lead. However, these folks have built up a trusted working relationship with the rest of the team and in some cases have revealed their identity to folks within the team, but are still anon to the public. There needs to be a certain level of trust and some level of identity confirmation before we can distribute Otterspace badges to signify they are contributors within the CDO, but this does not mean they have to fully reveal their identity. We can start a conversation with Otterspace to see if they have any ideas for a process here.

General Proposal Comments

It seems to be essential to establish a clear mission & vision before going through transition process. How will this being done?

Answer: The CDO Working Group is proposing an interim Steering Committee to create an initial draft of the mission & vision for 2023, utilizing existing works in progress (collaborative vision document, contributor offsites). Additionally, Apiary’s work aims to help the RadicleDAO develop a mission-aligned approach to ecosystem governance. They will do this by speaking to various stakeholders in the Radicle community and applying learnings from historical and existing governance structures outside of the web3 ecosystem. The goal is to have this work in a good place by March.
Only token holders can vote on this proposal, correct? Should we do a more open/public version of this call for them in the future?

Answer: This proposal in its current state is directed at CDO Contributors, but there will be a formal proposal submitted to RadicleDAO on February 16th (ushered by the Core Dev WG) to formalize the creation of the Core Development Org. This will include the Org Purpose with Annual Vision & Objectives, High level Org Structure and Roles, as well as the total annual budget requested. This complete proposal will be voted on by token holders, therefore there will be a public call to go through the proposal in full.

lftherios · January 17, 2023, 10:42am

Thank you for leading us through this transition!

What is the rationale for this first step? Why do we need it?

I am wondering if the right approach here would be to have contributors nominate others (one or more) rather than nominating themselves. My thinking is that ideally we want to create a culture where contributors recognise peers that have the expertise to lead them, rather than creating a culture of “campaigning”. Did you consider this approach?

shelb_ee · January 18, 2023, 10:06am

Hats Protocol Use Cases:

Hats Protocol is another tool we could use in addition to Otterspace badges to formalize and automate a few processes discussed in the proposal. Using Hats, DAOs can:

delegate & revoke authorities
hold contributors accountable
create role legibility

From a Hats Protocol team member:
We see Hats and Otterspace as composable, and we imagine many DAOs using both in the future for different uses. For example, in reading through the document above, I noticed two use cases in particular for which Hats might be useful:

Giving the Core Team Council absolute power in adding/removing a Steering Committee Member, and
Enabling dynamic elections of Core Team Council Members based on custom eligibility criteria

To expand on each in brief…

1. Giving the Core Team Council absolute power in adding/removing a Steering Committee Member: You could do this using Hats by having the Core Team Council multisig wear a hat, which I’ll call “Steering Committee Power Check Hat”. That hat could have admin rights over the Sterring Committee Member hats, which each SC Member would wear. Those SC Member hats would gate the SC multisig, such that wearing an active SC Member hat grants signing access to the SC multisig, with a max supply of 5.

This means, at any point, the Core Team Council multisig could take the action of revoking a SC Member hat from any one of the SC Members. That SC Member would then instantly lose their signing authority on the SC multisig and could then be removed from the multisig by the Core Team Council.

2. Dynamic elections for Core Team Council members: With Hats it’s possible to set the eligibility criteria for a specific hat to any custom logic you want, including delegating N tokens to a specific address. With this, core team members could vote for their representative on the Core Team Council using some logic (e.g., token delegation), and at any time, the person on the Core Team with the most delegated tokens becomes eligible to claim the Core Team Council Member Hat, which automatically adds them to the Core Team Council (along with the Core Team Council’s communication channel, multisig, etc.). The moment that person no longer has the most delegated votes, their Core Team Council Member hat is revoked, they lose the associated privileges, and the new person with the most delegated votes then becomes eligible to claim the role.

shelb_ee · January 24, 2023, 8:57am

A few more question have come up in private discussions that I want to share here & add some context to:

“Who do we expect these people [Steering Committee members & Core Team Reps] to be if we do the transition in 2 months?”

The Steering Committee Members will be members of the CDO, and not folks outside of the CDO/DAO. The intent was to have SC members come from within the CDO as they are closest to the development of the project and are involved in the intimate day-to-day, which is especially helpful when creating the annual vision for example. The Core Team Reps will also obviously be from within the CDO. The only position that could possibly be someone outside of the CDO would maybe be the IGF, but this person would probably not be outside of the DAO.

“Where will core team leads sit - either on SC or CTC?”

This we purposefully left open for discussion. I would be curious to hear thoughts/feelings about this before we go into the nomination process for the initial Steering Committee Members (see section quoted below).

“Would it be valuable for your team to do a quick survey of members of core teams to see what percentage of people would be willing to sit on the SC or CTC with or without additional compensation for doing so? The demotivating factors possibly being either regulatory and legal risk or simply the addition of lot of work and stress to take on.”

I would first like to note that the Steering Committee Members will be compensated for the work they do. How much / how is still up for discussion. If we look at responsibility/workload, we see that most of the work will happen in clear cycles (annual, quarterly) which helps make it easier to plan for. That being said, it will still be a decent amount of work during those time periods, and this should be taken into consideration in the compensation discussion.

Re risk & liability: With the CDO Design v2 complete at the beginning of January, Ange and I were able to spend the last two weeks speaking with legal counsel to try to clarify in great detail a) what risk is involved with the proposed CDO model b) what the probability of enforcement would be in different risk categories c) where the risk/liability would fall if something were ever to happen, and more. Then we will present important pieces regarding “risk and liability” for the CDO within the next week or two.

I believe it would be best to have this information clearly shared with folks before asking their “willingness” to participate in/be nominated for a SC seat.

lftherios · January 24, 2023, 9:04am

Another question I have is the following:

Who should be in the Core Development Org? Basically what is our definition of core development.

shelb_ee · January 24, 2023, 9:10am

@lftherios currently the Core Development Org would be made up of the following Core Team: Clients, Drips/Funding, Community, Marketing & Ops.

The definition of “core development” could be debated here (i.e. marketing & community are not technically “development”), but even the teams that are not necessarily considered development, they are directly supporting the dev teams. It is arguably more beneficial for these teams to all sit in the same Org and work together on developing strategy, mission, vision, etc.

lftherios · January 24, 2023, 10:39am

I think this is a very important decision to be made. Can anyone share the rationale for the proposed composition of the CDO? Nothing crazy just a few lines of which function and why.

cloudhead · January 24, 2023, 10:51am

What is meant by CDO “vision” here?

ange · January 24, 2023, 4:03pm

Hi Ele,

While “core development” is largely defined by the work of the product and engineering teams (i.e. Clients and Funding Core Teams), which maintain and develop the Radicle stack, the Core Development Org will also include the following core teams that support and amplify the work of Clients and Funding:

Marketing, which drives adoption of Radicle technologies
Community, we are still in the midst of defining what community work should be done in close proximity to product and engineering
Operations, which drives financial and operational accountability across the CDO

Community and Governance has, up until now, been one team. However, Governance intends to be spun off into its own Org supported by the RadicleDAO, since it’s really focused on initiatives at the RadicleDAO level.

To be clear: members of the Core Teams (Clients, Funding, Community, Marketing, and Operations) will be the ones who participate in electing (and “voicing” or petitioning the work/actions of) the Steering Committee.

Does that help clarify?

lftherios · January 24, 2023, 6:26pm

Yes that’s exactly what I was looking for. This makes sense. Thank you!

yorgos · February 6, 2023, 10:43am

Hi folks,

A bit late to the party here admittedly, but that was because I had assumed a rather different definition of “Core Dev Org” based on the name alone…

Given this definition of who is considered to be a part of the “Core Dev Org”, I have some questions:

If an idea for a “new” product/solution to be added to the “Radicle stack” comes up, will the team building that be part of this “Core Dev Org” ? Will that be a new “Core Team” needing to be onboarded? Will that be an application to the Steering Committee?
Have we considered - and rejected - the approach of different orgs for each product (code collab vs. funding) ? It sounds like we want to group multiple products, as well as their “supporting” functions (marketing, ops, etc.) within the same organizational unit (“core development org”) and I am wondering how those teams (marketing, community, ops) will be able to balance their priorities in supporting the 2 (to begin with) different products. At the same time, it sounds like the mission for these 2 products is quite different …
If the Steering Committee is the onboarding-decision-making body, but new Core Teams can mean additional workload for the other “supporting” core teams - that they have to agree to / staff for / plan for, does that mean that the STC alone cannot make the decision to onboard a new team ?
In terms of the composition of this org, a question about my own team: our work on incorporating Radicle functionality into the 2 most popular Integrated Development Environments (IDEs) certainly sounds like it also “supports and amplifies the work of Clients” and “drives adoption of Radicle technologies”. For context, we are building additional tooling that works on top of the rad CLI tool (and perhaps other “Clients”-produced tools in the future). Based on the definitions above, I am a little unsure if this team should continue to be funded through Radicle Grants or to transition to also be funded from this “Core Development Org” over time…

Apologies for the late feedback, but I didn’t think all these calls to participate in the calls were that relevant to our team, but after reading the comments on this post, I am not so sure any more…

Thanks in advance!