MIP23: Domain Structure and Roles

MIP23: Domain Structure and Roles

Preamble

MIP#: 23
Title: Domain Structure and Roles
Author(s): @LongForWisdom
Contributors: N/A
Type: General
Status: Accepted
Date Proposed: 2020/09/07
Date Ratified: 2020/10/27
Dependencies: n/a
Replaces: n/a

References

MIP23c4-Domain-Definition-Template
MIP23c4-Domain-Offboarding-Template
MIP23c4-Domain-Onboarding-Template

Sentence Summary

MIP23 provides a flexible and consistent structural framework for personnel working for MakerDAO within any domain.

Paragraph Summary

MIP23 provides a flexible and consistent structural framework for personnel working for MakerDAO within any domain. It defines two classes of roles, Domain Facilitators and Domain Contributors, and describes how they relate to one another. It also lays out guidelines for expansion into new domains, and how this should be defined under the MIPs framework.

Component Summary

MIP23c1: Domain Structure
Describes a consistent structure that can be used for any domain.

MIP23c2: Domain Facilitators
Defines the domain facilitator role in general terms.

MIP23c3: Domain Contributors
Defines the domain contributor role in general terms.

MIP23c4: Domain Definition MIPs
Suggests a template structure to be used to define specific instances of domain teams.

MIP23c5: Domain Structure Transitioning
Describes how MakerDAO will transition from the current domain team model to the new hierarchical domain structure.

Motivation

While MIP7 provided an initial starting point, it did not attempt to define how domain teams should be structured.

In theory, the open and permissive structure of having multiple teams within a domain that work independently has the advantage of decentralization and scalability. However in practice MakerDAO is not yet at the point where there are a sufficient number of qualified and willing personnel to support multiple teams. In fact, the open team structure may be inhibiting the growth and sharing of domain expertise due to the barrier for entry.

The domain structure defined in MIP23 is designed to promote knowledge transfer from current domain personnel into potential domain personnel via a facilitator-contributor model. In this hierarchical model, there is more of an opportunity for community members to be paid for domain work without immediately taking on longer term responsbility for that domain or having to pass a governance vote.

It is hoped that the addition of an explicit entry-level role will increase interest in these roles and leave the protocol with a larger pool of trained personnel to fulfil domain work.

Specification / Proposal Details

MIP23c1: Domain Structure

Specific role definitions of individual domains are not covered by this MIP, instead it seeks to lay out a generic, flexible and lightweight structure that can be used by all domains within MakerDAO.

Each domain is encouraged to build their own working structure under this umbrella to meet the requirements of their domain if they feel this is necessary. The key importance is to separate those with responsbility to the protocol, and those doing work for the protocol into two separate roles.

The first role is known as the Domain Facilitators. This position maps most closely to the previous Domain Team role. This position takes responsibility for the domain as it relates to MakerDAO and takes more of an organizational role. Persons in this role must be ratified by Maker Governance.

The second role is known as the Domain Contributors. This position is a working role that fulfils tasks as defined by the Domain Facilitators. Domain Contributors are not required to be ratified by governance.


MIP23c2: Domain Facilitators

The Domain Facilitators take responsibility for the success of MakerDAO as it relates to their domain. They will complete domain work themselves, or outsource to their Domain Contributors in order to fulfil their reponsibilities. Additionally, they will agressively transfer knowledge and attempt to grow the pool of personnel that can effectively work within their domain.

Each domain will have its own specific requirements and responsibilites, but it is suggested that domain facilitors keep the following principles in mind at all times:

  • Transparency - Be clear and upfront with the activities within the domain. Make every effort to inform Maker Governance of current work, issues, and concerns.
  • Effectiveness - Aim to complete work and resolve problems within the domain to the best of their abilities.
  • Present and Future Focus - Solve the problems of the present while being aware of the future impact of their actions.

It is recommended that Maker Governance aim to recruit and maintain three domain facilitators for each defined domain in the near-medium term. Three facilitators provides redundancy while allowing for knowledge transfer and on the job training within the role. Longer term, it is likely that this domain structure will change, or that a greater number of Domain Facilitators will be required.

At least one Domain Facilitator is required to explicitly and publicly approve any domain work that has been produced by a Domain Contributor before it can be used by Maker Governance. Any Domain Facilitator is able to explicitly and publicly veto the use of any unit domain work that has been produced by a Domain Contributor, this veto power takes precedence over the approval power. It must be expicitly and publicly communicated to Maker Governance which Domain Contributor(s) is responsible for any given unit of domain work.

The Domain Facilitator role within any domain is an elected role. Personnel must be ratified via a subproposal to be defined in each individual domain definition MIP (see MIP23c4.) A list of Domain Facilitators will be maintained within the domain definition MIP for that domain by the Domain Facilitators.

Each domain facilitator must provide a hardware-wallet secured ethereum public address to which they uniquely hold the private key. This address must be listed in the domain facilitator list for this domain (see MIP23c4). This address may be delegated powers or authority by Maker Governance at a future date.


MIP23c3: Domain Contributors

The Domain Contributors within a domain perform work on tasks within their given domain. These tasks can either be directly assigned by Domain Facilitators, or can be performed on a contributors own initiative.

Each domain will have its own specific requirements and responsibilites, but it is suggested that Domain Contributors keep the following principles in mind at all times:

  • Communication - Be clear and upfront with the work you are doing within the domain. Make every effort to inform the Domain Facilitators of the status of your current work, as well as any issues or concerns.
  • Effectiveness - Aim to complete work assigned as agreed with the Domain Facilitators to a high level of quality.

It is recommended that the Domain Facilitators attempt to cultivate and recruit as many Domain Contributors as possible within their domain. Redundancy is critical, and it is expected that Domain Contributors serve as the main source of potential candidates for Domain Facilitators.

The Domain Contributor role within any domain is not an elected role. Instead, an individual or team is officially labelled a Domain Contributor when domain work of theirs is approved by a Domain Facilitator. At this point, the Domain Contributor must provide a name or pseudonym, coupled with a brief paragraph describing their qualifications, experience or interest in the Maker Protocol. A list of Domain Contributors will be maintained within the domain definition MIP for that domain by the Domain Facilitators.

A team of individuals may also represent themselves collectively as a Domain Contributor if they desire to do so.


MIP23c4: Domain Definition MIPs

It is proposed that each domain operating under the Maker Protocol is defined within its own MIP, known as a Domain Definition MIP. A Domain Definition MIP must have at least the following set of components:

  • Domain Overview - A description of the domain itself.
  • Domain Facilitator Role and Responsibilities - A list of the responsibilities taken on by the Domain Facilitators.
  • Domain Facilitator Candidate Criteria - A list of the qualities and qualifications suggested for the Domain Facilitators.
  • Domain Facilitator Removal Criteria - A list of the criteria under which a Domain Facilitator should be removed.
  • Domain Facilitator List - A list of Domain Facilitators within this Domain.
  • Domain Contributors List - A list of Domain Contributors within this Domain.
  • Facilitator Onboarding Component - A process component that allows for the onboarding of a Domain Facilitator within this domain.
  • Facilitator Offboarding Component - A process component that allows for the offboarding of a Domain Facilitator within this domain.

MIP23c5: Domain Structure Transitioning

Given the current set of MIPs, the current domain team structure and the absence of Domain Definition MIPs for the existing domains, a transition plan is defined here and should be followed if this MIP moves to the Accepted status.

Until a Domain Definition MIP is produced for an existing domain, that domain will continue to operate using the previous structure and onboarding / offboarding proposals defined in MIP7.

When a Domain Definition MIP is Accepted for an active domain (Smart Contracts, Risk, Oracles) the following will occur:

  • Any reference to ‘Domain Teams’ in existing MIPs should be modified by the MIP Editors to reference the appropriate Domain Facilitators.
  • Members of currently ratified domain teams will become Domain Facilitators under the new structure automatically.
  • Any individual or team that has provided approved domain work in that domain will become Domain Contributors under the new structure automatically.
  • Any reference to MIP7 related to that domain in existing MIPs should be modified by the MIP Editors to reference the newly created MIP.
  • The MIP Editors will use their discretion when making the above changes with the aim of matching the intention of the transition to existing MIPs to the fullest extent possible.

Once Domain Definition MIPs have been produced for the Oracle, Risk, and Smart Contracts domains, MIP7 should be moved to deprecated status by the MIP Editors and should no longer be considered active or usable. At that stage, any reference to MIP7 within other MIPs should be modified to reference the appropriate Domain Definition MIP by the MIP Editors.

In the case that there is no MIP Editor, the Governance Facilitator(s) should make the above changes to the MIPs as described.


10 Likes

It is quite some MIP you have proposed here Long, took me some time to digest it.

So what we are looking at here is the possible future state of Maker post Foundation shutdown. Smaller, focused groups doing their thing within defined borders. I really like it and I do not really see any theoretical reason it would not work.

While your MIP lays out a possible structure for Maker, it does not mention how the structure will be financed or any starting point with regards to a philosophy of incentives.

So just to do some napkin calculations: we already have the domains of Risk, Oracles and Smart Contracts. Additionally practically every organization of a certain size has departments (or domains) for Marketing, Legal and Accounting. There is also the deepdive into possible future use cases and demos for the ecosystem so this would possibly fall under a R&D domain. After all, Centrifuge enganged with Maker for a year or so prior to reaching out to the community.

Possibly the Interim Governance Facilitator role will grow into a General Management Domain. In total we are looking at +/- 8 domains with a suggested total of 24 Facilitators and as many Domain Contributors as possible - according to this MIP.

So my first comments have to do with financing of this MIP from Maker’s perspective. There needs to be funds set aside specifically for the purpose of financing governance. Already this will possibly eliminate any chance of ever going back to 0% effective fees as expenses needs to be met. Alternatively there is continued MKR dilution. The community will need to make a choice on how this will be financed.

Then there is the question how Facilitators and Contributors are compensated, which is a whole minefield on its own. For Facilitators you could do individual compensation based on qualifications, the problem being that there are few things that really prequalifies anyone for crypto and with up to 24 Facilitators you will need a whole HR domain to handle it. Alternatively just pay everyone the same.

Then there is the question on how Domain Contributors are compensated. If indeed

are recruited, will these be paid by the Facilitator that recruited them or directly by Maker? If Maker pays the HR/Accounting domain will be immediately needed, if the Facilitator pays there is much less bureaucracy but also less contingency and increased risk for non-intended practices. With a tonload of Contributors there is also limited scope for compensating them. The Contributor role is planned as an entry level position - but what other options does a good potential contributor have? I think limiting the number of Contributors to a fixed number per Facilitator is perhaps the first thing I would suggest.

And what kind of people do you imagine in these roles? Are the roles of Facilitators and Contributor full times positions and will be compensated as such? Or are we talking hobbyists, part-timers, students, MKR whales etc etc?

5 Likes

Laying it out visually, is it correct to say that this MIP takes each domain as a box split in a “management” team who directly answers to the DAO, and an operational team who works under the supervision of management; and additional boxes can be created through MIPs?

I like the structure being laid out here, and it’s quite important for the future of Maker. I think there are two missing elements.

  • As mentioned by @Planet_X , compensation is missing from the picture. This is probably itself a Domain, since day to day budgeting decisions should not have to be handled by executive governance votes.
  • Not to impose a top-down structure, but a “central team” with a guidance role for other Domain Facilitator teams would probably accelerate action in the normal course of operations. A little like a Foundation embedded inside the governance instead of deployed around it.
  • Also what’s the general term for someone who is compensated by Maker? Domain Participant?

Regarding compensation, two things:

  • To make the transition easier, once a compensation framework has been decided, the Foundation should fulfill that part of the framework (both financially and operationally) until the rest of the teams have been moved into MIP23. Then the funding source for compensation would switch to whatever the DAO has decided.
  • A little tangential here, but specifically for compensation I’m in favor of strategic printing&selling of MKR towards a compensation buffer because 1) the surplus buffer is encumbered by what happens during ES 2) the SF might have to go to 0% sometimes, and 3) even in the absence of revenue, revenue prospects still give value to MKR which can be cashed out for continued operations. Also, to give peace of mind to participants who have their life to organise, any further backstop should not depend on any DAO funding source but on an external insurance-like service paid for by the DAO.

Really appreciate the feedback @Planet_X and @swakya.

So I appreciate the thoughts on compensation guys, and I agree it’s a complex subject with its own issues and pitfalls. That said, I do think it’s important to keep the compensation setup separate from the more general domain structure setup. In general a MIP is supposed to focus on one thing, and I think it is possible and desirable to separate compensation from structure. I feel this is beneficial for the following reasons:

  • It makes the individual MIPs shorter and more focused.
  • It allows swapping out of one MIP independent of the other. Now this won’t always be possible, considering how the two subjects are related, but I can see for example the structure staying the same while the compensation MIP is swapped out.
  • It makes it easier to get traction on the problem when you have one semi-fixed part. Meaning it’s easier to figure out compensation once the structure has been ratified and is semi-fixed.

Compensation will definitely be the subject of another MIP in the (hopefully near) future, though it may not be written by me.


This is something I think we’ll see in practice. But I’m not sure it should be a hard requirement ratified in a MIP.

I actually think there is a lot of flexibility here, though moreso for contributors than facilitators. That flexibility will hopefully allow Maker to appeal to skilled people in a wider variety of situations.

Pretty much, yes. There is flexibility within the domains to create a more nuanced structure as required. But from the DAO’s perspective the important divisions are:

  • Facilitators = Responsible for the domain.
  • Contributors = Working within the domain.

Not sure. Domain member? Domain participant? Domain worker?

So this is probably outside the scope of this MIP. I have considered such an idea in the past. We’re in this sort of weird interim stage where there is something of a lack of leadership direction. In the future the hope is that once we have delegation, a number of prominent delegates arise, and will fulfil this role.

3 Likes

Regarding compensation, first order of business is to hire a treasurer and determine a monthly budget that can then be doled out to domain teams. Once that is in place it will be much easier to develop subsequent domain teams.

Is there someone trustworthy within the foundation who could MIP themselves into a treasurer domain team role?

Point well taken :slight_smile:

What did you have in mind here?

Apart from redundancy and knowledge transfer, maybe one Faciliator should be highlighted as responsible for moving things forward; otherwise a flat 3-person structure has a risk of diluting energy. What do you think?

I think the MIP should explicitly allow for Facilitators to double as Contributors within the same Domain. Especially in the beginning with a scarcity of people with the right skills, there will be a strong overlap between people who make good Facilitators and people who make good Contributors for a given Domain (there is an obvious self-dealing risk here but this is just a specific case of favoritism risk, which would be kept in check by governance).

Re: # of Contributors per Facilitator,

Agreed. This seems best treated on a case-by-case basis.

re: “central” team

I hope that will happen, but to me this is leadership at the governance level, which is different from leadership at the operational level. Long-term, the former would look at larger, more ideological questions, while the latter would have a coordinating & accelerating role on immediate and medium-term matters. So to me it’s very much within the scope of this MIP, as in it could at least mention a special “coordination domain”.

Mainly that in the ideal world, facilitators can sign-off on things without needing input from the others. However, this opens up issues on a larger scale. I was imagining a situation where each facilitator had a group of contributors, and might be biased when approving work from them. The power of veto requires the facilitators to communicate more meaningfully on each piece of work.

There might be better ways to achieve this though, and it might just be a case of trying to future proof this a little too much. Open to removing it if you agree.

So this is a concern. I feel like three is the sweet spot where you don’t lose too much momentum from the diffusion of responsibility but you still have an increased capacity and redundancy. It’s definitely a trade-off though. In practice I think that the structure in each team may not be entirely flat (which is fine), there will always be a ‘most senior’ guy who tends to take the leadership role. But I think it’s important that they all have the same powers on paper to help with the redundancy part.

Yeah, so this isn’t explicitly said, but I definitely include ‘doing domain work yourself’ as part of the ‘taking responsibility for work.’ Agree that there is no harm in being explicit here though. I’ll make that change when I do my next pass.

Hmm, I agree there is a split between leadership in longer term strategy and leadership in day to day operations. I think I disagree about including it explicitly as part of this MIP though. If this idea reaches general agreement, I’d suggest that it should be its own domain, and be defined according to MIP23c4 like any other.

1 Like

In the medium term, this is probably @amyjung as an (interim?) operations domain facilitator. The Foundation is actively working on how the compensation side works, I’m trying to fill in some of the structural side and just make it easier to add new domains from a MIPs perspective.

1 Like

re: veto power of facilitators:

I actually like it, in that things would grind to a halt if there was a conflict between facilitators, which is a failsafe and one hopes would encourage governance to react quickly. So I vote for keeping it :slight_smile:

How about explicitly leaving the on-paper power separation open in the MIP? For instance consider the scenario of a completely new hire learning under a senior facilitator; maybe their hardware wallet should be included in the list only after a trial period, or should have reduced powers for a while.

Great!

I’m OK with that.

1 Like

Yeah. Might be a good idea. I need to think about it a bit more. I was sort of imagining people would do some of the responsibilities as contributors and only being onboarded once they had a good handle on things. But that almost contradicts the idea of doing knowledge sharing + onboarding as part of the facilitator role.

1 Like

Made changes to respond to comments. Added templates for domain definition MIPs and their subproposals. Diff can be found here:

Linked files can be found here:

I’m not sure how you can guarantee an address comes from a hardware wallet. Would it be more clear to say, “is expected to maintain a hardware-wallet”

Will this be an active list, or a historical list? If someone participates, contributes, and then feels its not right for them, will they be taken off the list?

I’m guessing this is going to be a fairly subjective criteria list. This is bound to come up in Maker’s future, and it may be beyond the scope of this MIP, but I’m wondering how the community is going to deal with a Facilitator that loses productivity/interest, and generally fades, but still wants the position, likely for compensation.

In general this is really great and a pretty organic next step. I’m worried about incumbents in the future. Wondering if these positions will be “for life” or if they will periodically be up for re-ratification or something. I would like all-star contributors to climb the ranks if they wanted to.

2 Likes

Minor changes:

Moved to Formal Submission.

1 Like