[Ideation] SCP-151: Amendment to SCP-92: Definition of a Workstream Leader

Proposal Discussion
1

Incubation post

Summary

This proposal adds two points of clarification to SCP-92: Definition of a Workstream Leader.

Abstract

In pursuit of its mission, the ShapeShift community has delegated authority and resources to Workstream Leaders. The benefit of this framework is that it enables workstreams to move and build quickly without burdening themselves or the governance process with minutiae. The risk is that workstreams could use the powers granted to them to move in a direction that either hasn’t been approved by the community, or worse, has been explicitly disapproved.

Motivation

The motivation of this proposal is to clarify the boundaries of workstream leaders’ authority, making it clear that workstream leaders do not have the authority to override past community governance without passing a superceding proposal, nor do they have any powers not explicitly granted to them via governance.

Specification

If this proposal passes, the following two paragraphs will be added to the Single Workstream Leader section of SCP-92: Definition of a Workstream Leader.

  1. Workstream leaders do not have the ability to make decisions that have explicitly been disapproved by governance unless the disapproval was explicitly superseded in a subsequent proposal.

  2. Workstream leaders are expected to act in good faith and to use the powers and trust bestowed upon them to enact decisions ratified by governance to the best of their ability.

  3. Workstream Leaders do not have any unique privileges relative to other community members that aren’t explicitly granted to them via governance.

–

To guide any workstream leaders or community members who wish to pass a superseding proposal on any matter in the future, a brief section on Superseding Proposals will be added to the FOX Governance process. This section will specify that in order to supersede a past decision made by governance, the superseding proposal must explicitly state the name, the SCP#, and the portions of the proposal it supersedes.

If passed, this amendment will apply to all past and future proposals until it’s explicitly superseded.

Benefits

  1. Clarify the boundaries of workstream leaders’ authority

  2. Ensure that ShapeShift community governance continues to be the highest level of authority

Drawbacks

  1. If community members and/or workstream leaders change their mind about a decision, they need to pass a superseding proposal before effectuating the decision

Voting

For: amend SCP 92

Against: do not amend SCP 92

2

Stipulation #1 seems clear and unambiguous. My concern here is that “Workstream Leaders do not have any unique privileges relative to other community members that aren’t explicitly granted to them via governance” feels overly vague and could lead to the inclusion of all sorts of super-detailed carve-outs in Workstream Proposals and future SCP-92’s. Thus we go down the route of language bordering on legalese and a proliferation of DAO lawyering, which could potentially weaken the governance process by a.) discouraging participation (because nobody wants to read through all sorts of legalese), and b.) making it harder to understand what’s going on.

I understand the slippery-slope fear that you and some other community members have voiced. To use one of concerns that was brought up, what’s to prevent a WSL from unilaterally voting to send themselves the entirety of their WS budget? However, let’s bear in mind that the community can quickly (within less than two weeks) weigh in on any WSL decision that anyone in community deems to be undesirable. The current WSL fee proposal posted by Ron is a perfect example of how this dynamic works. Governance provides the ultimate check against anything a WS Leader does.

So my suggestion would be to define specific things in this proposal which are time-sensitive. These would be things which could harm the DAO prior to the community weighing in via governance. AFAICT this pertains primarily to budgetary matters. Something like “Workstream Leaders cannot unilaterally send funds from their WS Colony balance in a way to contravenes the WS budget that was approved by governance” would directly address that concern.

To elaborate a little more on the ambiguity…Stipulation #2 is so broad that all sorts of things could be challenged under that definition. For instance, WS Leaders having a regular DAO-sanctioned leadership meeting is not defined by governance as a “unique privilege” of Leaders, yet it’s something that’s organically become part of the DAO’s weekly operations. Does that mean we’ll have to stop having this meeting if this passes? Similarly, I worry that the overly-broad definition of Stipulation #2 opens the door to governance concern trolls (for lack of a better term) who might challenge even single decision not specifically scoped out by governance, even if the community at large doesn’t see a problem with it.

So I understand the motivation behind this proposal - but we need to tread carefully here and think about how this might impact governance down the road.

3

Thanks for the feedback @seven7hwave! Definitely agree we don’t want to drown ourselves in a sea of legalese. Hoping we can find the right balance of clear and concise language that gives sufficient power to Workstream Leaders to execute while ensuring that the community maintains ultimate authority.

Stipulation #1 is the addition I feel the strongest about. After the debate around whether Workstream Leaders have authority to override past governance decisions or whether the two words “monetize defi” in SCP-145 were sufficient to override SCP-128, I think stipulation #1 is an important clarification that will effectively derisk this or similar scenarios from occuring again. Glad you agree it’s clear and unambiguous.

I hear your concerns on Stipulation #2. That wasn’t the intention, but it’s a great example of how the same language can be interpreted in different ways. The intention wasn’t to require that Workstream Leaders get explicit permission for every action they do. Rather, it is to ensure that Workstream Leaders cannot grant themselves additional powers that haven’t been approved by governance. I hope this stipulation never comes into play, but felt that it adds worthwhile clarity in the event that a Workstream Leader(s) attempts to do this in the future. Aside from Product and Engineering’s decision to enable fees and the events that triggered SCP-92 initially, I haven’t seen any examples where Workstream Leaders have felt the need to exercise powers that hadn’t been explicitly granted to them by governance. Rather, I believe the following examples of additional powers being granted by governance rather than assumed by Workstream leaders are the right way to dao things, and hope that you and the community agree: SCP-107, SCP-113, SCP-135, the upcoming SCP-150, and moderation’s workstream proposals.

Workstream Leaders already have the following broad authorities granted to them in SCP-92:

“The Workstream Leader shall be responsible for the direction, resourcing, budget, performance, deliverables, communication, and representation of the workstream.”

I think it’s important to draw a line of where this authority ends so the argument can’t be made for instance that because a Workstream Leader is responsible for their stream’s deliverables, they can do virtually anything. I think a good place to draw that line is governance, including the existing SCP-92. If the community or Workstream Leaders wish to delegate additional authority in the future, they’re welcome to make a proposal. This will also help the community keep track of which authorities have been delegated to Workstream Leaders in case they ever want to revoke or transition this authority.

In the example of an argument being made that Workstream Leaders could not meet privately without governance approval, I would argue that the ability to meet privately with whoever you choose is not a unique power that Workstream Leaders have relative to other community members. If you or other community members still feel this Stipulation could cause more harm than good, I’m open to modifying or removing it though; please lmk what you think.

To your point on WS leaders having the authority to send their entire month budget to themselves, technically they do have this power currently and it is a real risk. While we could amend SCP-92 to say they can’t do this, unless we either remove the ‘Force’ permissions on Colony (something I do think we should do when the new version of Colony comes out soon) or migrated Workstreams to their own multisigs, there is nothing to actually stop a WS leader from doing so. Considering it’s likely that a WS leader who did do this would be swiftly removed via governance regardless of this stipulation, I’m not convinced it’s worth adding language like you suggested that prevents Workstreams from deviating from the budget outlined in their initial proposal; often Workstreams do modify their budget mid-cycle, and in general I think it makes sense to defer to the Workstreams and give them this ability without requiring additional proposals. When the force permissions are removed on Colony, Workstream contributors will have the ability to object to any payment motions created by Workstream Leaders, which I think is a nice system of checks and balances to effectively mitigate this risk.

I like the spirit of giving Workstream Leaders authority to define specific things which are time-sensitive and could cause harm to the DAO prior to community governance weighing in. On this note, I believe this is a power that the Treasury Signers have, either implicitly or explicitly; there is certainly precedent for this when the Signers removed the FOX/FOXy liquidity from Elastic Swap to protect against a potential exploit. As another system of checks and balances, I think it would be best to leave this power with the Treasury Signers rather than with a Workstream Leader or group of Workstream Leaders. That’s my initial reaction, would love to hear your any others thoughts on this.

Thanks again for the thoughtful feedback!

4

Thank you for bringing this forward @willy ! While the intention behind the amendment is clear, there are areas that could benefit from further clarification and consideration:

Review Mechanism: Introducing a more rigid process necessitates a mechanism to revisit this decision periodically. This would allow us to assess its effectiveness and make adjustments based on real-world experience.

Stakeholder Engagement: As this amendment directly impacts workstream leads, their feedback is crucial. Engaging with them can provide insights that might bring to light potential challenges that haven’t been considered.

I share @seven7hwave 's sentiment that Retroactive governance can be a slippery slope. If we’re not careful, we might inadvertently introduce governance fatigue by requiring frequent permission votes. Scenario mapping might be a more efficient approach than trying to push this amendment quickly.

As an aside, Votes designed mainly to block or restrict actions can lead to confusion, especially when there’s no governance team to oversee them or review them. We should be wary of creating a situation with conflicting proposals, sub-amendments, and other complications.

Illustrative Examples: It would be helpful to provide scenarios where workstream leaders might feel the need to supersede a decision without a new proposal and situations where they shouldn’t. This would give a clearer picture of the practical implications of the amendment.

Emergency Situations: There should be provisions for emergencies where swift action is required. Clearly defining such emergencies and providing a fast-track process for them could be beneficial.

Defining Boundaries: It’s essential to delineate the boundaries of a workstream leader’s authority explicitly. While they should have the autonomy to achieve their goals, there should be clear limits to prevent potential overreach.

I think it’s important to draw a line of where this authority ends so the argument can’t be made for instance that because a Workstream Leader is responsible for their stream’s deliverables, they can do virtually anything

To address the point about workstream leaders wanting to “do virtually anything” – the core idea, i think, is to ensure that workstream leaders act in good faith, aligning with the goals and vision of the FOX community. Perhaps incorporating “in good faith” into the amendment would add the necessary clarity and reassurance.

5

I like number 1 and think it’s clear:

  1. Workstream leaders do not have the ability to make decisions that have explicitly been disapproved by governance unless the disapproval was explicitly superseded in a subsequent proposal.

I don’t understand #2. Maybe you can give an example of what this point is trying to address.

  1. Workstream Leaders do not have any unique privileges relative to other community members that aren’t explicitly granted to them via governance.
6

I hear the feedback on point #2 and have since replaced it based on a suggestion from @0xFBL, thanks for the feedback @seven7hwave, @0xFBL, and @joshuAF. Open to modifying or removing the updated point #2 too as I mainly would like to keep this proposal focused on point #1, as I think it’s very clear and unambiguous, and will provide some apparently necessary clarity.

7

“I share @seven7hwave 's sentiment that Retroactive governance can be a slippery slope. If we’re not careful, we might inadvertently introduce governance fatigue by requiring frequent permission votes. Scenario mapping might be a more efficient approach than trying to push this amendment quickly.” - @0xFBL

Workstream leaders have never needed to ask for permission for every decision, nor will they need to if this proposal passes. There will be no question however that in order to go directly against explicit proposals that the community has ratified, such as SCP-128, workstream leaders will need equally explicit permission.

Unfortunately I think this amendment does need to be pushed quickly as the added fees on THORChain have yet to be disabled under the argument that the 2 words “monetize defi” in SCP-145 were sufficient to override the very clear SCP-128. Workstream leaders thinking they can override explicit governance without equally explicit community consent is the slippery slope that I’m concerned about. If the community finds that this somehow overwhelms governance, they can always give Workstream Leaders more power. So far this hasn’t been an issue, and I believe most workstream leaders were already operating under the understanding that the community rather than Workstream Leaders are the ultimate authority. Feel free to share any scenario maps where you think this could cause trouble though.

I am fine with adding a bullet point that “Workstream leaders are expected to act in good faith and to use the powers and trust bestowed upon them to enact decisions ratified by governance to the best of their ability.” not sure if it’s necessary, but that’s how i felt about #1 before too, and I certainly don’t think it would hurt. Replacing point #2 with this.

If any workstream leader or community member still feels these are either too restrictive or not sufficient, would love to hear your thoughts.

8

I’ve also added the following sentence to the Specification section in the spirit of explicisity: If passed, this amendment will apply to all past and future proposals until it’s explicitly superseded.

9

@willy

I think that the updated language in #2 introduces ambiguity and room for interpretation and that’s exactly what we’re trying to avoid.

How do you define “in good faith” objectively? Is taking an explicitly prohibited action during an “emergency situation” or making a decision “out of concern for the long-term best interest of the DAO” that is against its clearly-stated wishes something that could reasonably have been considered to be undertaken “in good faith?” The road to hell is paved with good intentions.

The intent of the original #2 was clear to me - “The authority outlined in SCP-92 (and any directly superseding proposals) shall be taken to be comprehensive. Workstream leaders may not assume any additional authority not explicitly described therein.”

I see major pitfalls in the updated language where discussions about what to do in response to egregious violations of DAO mandates or unauthorized expansions of authority quickly devolve into conversations about intent and interpretation of language.

10

Hey Frens,

I think workstream leaders need the ability to move laterally. I think changing the language will result in needless and time-consuming proposals moving forward where there is a constant need for approval for arbitrary changes that will hinder maneuverability (no, i’m not saying fees being enabled is arbitrary). Did @0xFBL act outside his authority? Maybe… Do we need to do a whole song and dance around it? No. I don’t believe so. Rather than redefining terms and debating over word definitions, lets just put the exact perceived overstepping of authority to vote. Do we think he overstepped? Vote. If so, we can agree that he got it wrong this time and then fees will need to be disabled.

I think this was a good thing overall because it catalyzed a much larger and much more important discussion. We have had an incredibly productive debate on tokenomics, platform fees, voting reform, fox rewards… This debate has been needed for a long time and I think the fee switch is what got that ball rolling.

It feels unnecessary and petty to redefine terms and debate whether someone was acting in good faith or not… or whether they had the authority. I think its a gray area, but a vote on that specific question would suffice. The language will never be devoid of some interpretation or theory that can be used and there will always be someone on the other side of that.

11

cuckboy wasting time again. get good willy boy

12

Thanks for sharing the feedback @pastaghost. The intention with point #2 wasn’t to give workstream leaders any additional authority, but rather just to clearly state an expectation for workstream leaders that I think is hard to argue with. I can see your point that this could create a scenario where a workstream leader does something that they aren’t authorized to, and then tries to justify by saying it was in good faith. However, that risk already exists despite this language, and in either case it would be up to the community to decide if/how to enforce.

I can see this point is contentious and already being interpreted differently. As stated earlier, I feel most strongly about point #1, so I’m open to removing point #2 entirely and keeping this proposal focused on point #1 which doesn’t seem to have any contention.

There has been some strong push back on the original point #2. I definitely hear your arguments for it, but also hear the arguments on the other side. I couldn’t really think of a scenario where it would be necessary that isn’t already covered by point #1. If you have any scenarios in mind, please share as that could help convince both me and other community members.

13

gm @N0L1F3 and thanks for the feedback. it’s awesome to see you getting more involved in governance and i always appreciate your perspective.

Is your issue just with point #2, or are you concerned about point #1 as well?

I can understand the feedback with #2 and am open to removing it; it’s already being interpreted in unintended ways.

I feel pretty strongly that point #1 is a no-brainer though. I think myself and many others felt this was already implied and were surprised to not only see how fees were enabled, but also surprised with the justifications and rationalizations made along the lines of “well this is how DAOs work. the core team does what they think is right and then asks for permission afterwards.” While that may be how some “DAOs” choose to operate, I couldn’t disagree more. If workstream leaders have the authority to go directly against governance and then unilaterally justify their actions as long as they make the argument that non-explicit language in a subsequent proposal gave them that authority, it’s a slippery slope that in my opinion negates the entire purpose of governance in the first place.

I’m going to remove point #2 after seeing all of the ambiguity it’s already causing, but hope you’ll agree that #1 is worthwhile. If the community wants to enable fees, they can support def1’s or another proposal to do so. if they want to give workstream leaders this authority, they can support SCP-150. Regardless, I think point #1 is clearly important to include to draw a clear line on where Workstream Leader’s already expansive authority ends.

14

Alright point 2 has been stricken. thanks all for the feedback :pray:

15

very surprising to see so many votes against

16

Same, it shouldn’t be this controversial to clarify that Workstream Leaders do not have the power to cancel/supersede a governance decision. I’m actually surprised to see many Workstream Leaders here voting against this (and thus not willing to put this to a vote by the broader category of FOX voters), it’s worrying to say the least.

Just so we’re clear though, even if this clarification proposal was to not pass governance right now, the fact will remain: Workstream Leaders do not have the power to go against a voted governance decision, this power was never granted to them anywhere and certainly not in SCP-92.

There is also no “urgency” clause anywhere that would allow Workstream Leaders to skip the governance process (or not wait for it to complete) with their own executive decisions. If they want such powers, they can attempt to change the governance process, through governance. Attempting to force it like it has been done is certainly not the best way to convince people that they can be trustworthy with it in my opinion.

17

great point @Fireb0mb1

had always personally felt that this was implied. didn’t consider until now the possibility that this proposal being rejected could be construed as an argument that workstream leaders have always had this authority.

surprised to see this many votes against it, but glad that as it currently stands this is on track to go up for official vote where the maximum # of community members will have a say. thanks to everyone that has voted in favor and/or voiced their thoughts on why this is an important clarification🙏

18

One suggestion @willyfox - if/when this goes forward to formal vote from ideation. I think you should add one example of what the language for a superseding proposal should look like under this amendment.

e.g. I think the way @0xdef1cafe worded his recent fee/tokenomic proposal would be sufficient under this, and that could prove as a great example, he wrote “This proposal directly supersedes SCP-128” at the beginning of his proposal.

If you agree that is correct then include an example like that and if you don’t think that is sufficient then make sure to include an example of what would be sufficient.

19

Agreed. Should this proposal pass, I suggest that any future proposals seeking expansion of the authorities outlined in SCP-92 should contain the text “this document shall supersede SCP-92” along with an explicit and comprehensive description of the expansion of authority being requested.

20

Thanks @jonisjon :pray: I’ve alluded to this in the Specification section and will add specific language including an example when it goes up for official vote