Steward WG 3-month funding proposal (May - July)

Tamara · May 12, 2022, 7:30am

The first 3-month funding covered Feb, Mar and April.

This is a proposal for funding for the Stewards WG for May, June and July.

Key information

Proposal title

Steward WG 3-month funding proposal

TL;DR

The purpose is to provide compensation for the Stewarding and the coordination efforts of active Stewards and Working Group Coordination Leads (WGCL).

Proposal description

This proposal takes into account these assumptions:

Not all WGCL participate in the transversal coordination and those that do not are not compensated as part of this proposal. (They should be compensated as part of their WG’s proposal).
Stewards and WGCL should also be compensated in the WG in which they are active contributors. So, this is the additional compensation for the transversal activities they are responsible for and for their dedication to staying up to speed on everything that is happening in the TEC and our 11, and counting, working groups.
Factors in a small budget for special projects and bounties that support the WG objectives.

About Stewards & Working Group Coordination Leads (WGCL)

Stewards and WGCL are a critical to our success at the TEC. They keep the ship moving forward and on-target.
Stewards:
- are the MVV super-spreaders,
- carry the know-how of the TEC (e.g., how we are organized, whom to ask about what, what projects are active across multiple WGs),
- represent the TEC to the larger community,
- raise, debate, resolve, coordinate, advocate, propagate,
- are the civil servants of the community.
- Expected time commitment: At least 10+ hours per week to keep active and “on top” of what’s happening, attend the Weekly, Council and Community calls, other WG calls, etc.
WGCLs:
- are responsible for streams of work contained within a WG. For the coordination and surfacing inter-wg dependencies.
- Expected time commitment: At least 10+ hours per week. Attending the Sprint planning & retro, Weekly call, Council call, WG calls, etc.
Stewards and WGCL may be active contributors in more than one WG.
WGCL may also be Stewards although not always.
Stewards may also be WGCL although not always.
Stewards and WGCL should remain active and present. Inactivity would be cause to self-offboard or be nominated for offboarding. The process by which that happens is outlined in the Stewards’ Manifesto.

Additional information to add

For the first 3 months of funding from the previous proposal, Stewards and WGCL were compensated in xDAI.

For this funding proposal we will be distributing compensation in TEC tokens.

Advantages:

Compensating the Stewards and WGCL with our own token will increase their governance weight, should they choose to hold onto them.
Creates buy demand for the TEC token itself.
Will serve as a discovery mechanism to surface challenges of compensating contributors with the TEC token. Eventually this is something other WG may decide to do as well.

How will this work:

Stewards multisig will hold xDAI and convert what is needed for that month’s compensation into TEC around the first week of every month.

How does this proposal benefit the community or the field of Token Engineering?

Stewardship is the engine that keeps the TEC running. We also like to think we are building repeatable processes, practices and tools for other TE DOAs to utilize for themselves.

Amount requested (Only for conviction voting)

48,750 xDAI

Address (multisig): gno:0xA3b2391a209b906FE29d4D4285782F18E38fA525

How will these funds be used? (Only for conviction voting)

Role	Monthly	Role/Budget	#ppl	Monthly	3-month
WGCL	750	WGCL	9	6750	20250
Steward	500	Steward	15	7500	22500
Special projects	2000	Monthly projects budget	tbd	2000	6000
			Totals:	16250	48750

*The compensation is cumulative. If someone has the responsibilities of both Steward and WGCL, they will receive compensation for both versus a member that is energizing the role of one or the other.

How will you share progress?

We seek to keep this process simple and transparent. During the first week of each month, each Steward or WGCL will post their compensation request on the #Steward discord channel. The post will include their role, work performed and associated github issues. If no objection is raised, the amount will be transferred. If an objection is raised, it will be mediated internally in the WG. If it is not able to be mediated within the WG, a Gravity form will be opened for assistance in mediation.

Complementary information

Project information

Community Stewards WG Manifesto

Team Information

Stewards

At the time of this proposal there are 15 Stewards.

Chuy
Eduardo
Gideon
Griff
Ivy
Juan Carlos
Lauren
Livia
Mitch
Nate
Sebnem
Tamara
Vyvy-vi
Ygg
Zeptimus

Working Groups & WGCL (if the WG participates in transversal coordination events)

At the time of this proposal there are 9 WGCLs.

Working Group Coordination Leads (WGCL)

No.	Working Group	Steward	WGCL
1	Community Stewards	Tamara, Nate	MountManu
2	Soft Gov & Culture	Livia	Livia
3	Transparency	Ivy, Zeptimus	Zeptimus
4	0mega	Sebnem	Mert
5	Gravity	Juan Carlos	Juan Carlos
6	Legal	Ivy	Ivy
7	Communications	Chuy	Chuy
8	Labs	YGG
9	Communitas	Eduardo, Tamara	Tamara
10	Rewards System	Mitch	Kristofer

Previous experience and interests

These are all the active Stewards and WGCLs in the TEC now.

gideonro · May 12, 2022, 7:30pm

A few questions about the xDAI > $TEC conversion:

$TEC is super stable relative to the rest of the market, but it still fluctuates - how do we help protect folks from just happening to have bad timing at the time of conversion?
Are we using the ABC for conversion, and if so, will we convert all of the funds at once or person by person? The latter could create some undesired differences in price as demand pushes it up. The former could create some slippage, but I’m not savvy enough about the ABC dynamics (yet!) to understand how that would affect things.
I’m assuming that the calculation for the conversion will just take into account the tributes, and that that doesn’t matter because the tribute just goes back into the common pool anyway, right?

P.S. I’m excited about the possibility of paying in $TEC.

Tamara · May 13, 2022, 5:22pm

$TEC is super stable relative to the rest of the market, but it still fluctuates - how do we help protect folks from just happening to have bad timing at the time of conversion?

The xDAI from the multisig will be converted to TEC right before the distribution itself. We can let everyone know when it happens. The relative stability of the TEC because of the ABC (in comparison with the token dumps that are happening all around us atm) does offer some small protection. If anyone has any other ideas for this, please shout them out.

Are we using the ABC for conversion, and if so, will we convert all of the funds at once or person by person? The latter could create some undesired differences in price as demand pushes it up. The former could create some slippage, but I’m not savvy enough about the ABC dynamics (yet!) to understand how that would affect things.

All at once. Then the mutisig will hold the TEC and distribute. Probably secondary market instead of ABC.

I’m assuming that the calculation for the conversion will just take into account the tributes, and that that doesn’t matter because the tribute just goes back into the common pool anyway, right?

We will have to factor this in, yes. Though using the secondary markets does alleviate this consideration.

The Stewards being compensated in $TEC is a large step forward! Eventually, we can imagine compensating all contributors in $TEC and even funding proposals in $TEC.

gideonro · May 13, 2022, 7:09pm

I agree. This is a step forward on multiple fronts.

One approach to dealing w/ the fluctuation that we’ll still face would be to break the trades into a few chunks over time (like a dollar-cost-averaging strategy). That might also help reduce slippage too. Just a thought.

JessicaZartler · May 15, 2022, 5:48pm

Nice to see the $TEC initiative!

A question/suggestion: are the stewards or any working group addressing or planning to address long-term budget planning and/or sustainability of the common pool and viable business models/value production?

This seems to me one of the biggest challenges ripe for R&D. The ABC is a boostrapping mechanism and operates under the assumption that there will be volatility funding the pool. Of course, we will see more when vesting unlocks but if not already in the works, this would be an imcredibly valuable focus over the next months if not already in the works.

Also would be interesting to get a feel for what the community desires in regards to %s of funding going to operations/admin, research & development and other buckets.

One more thought was around crisis planning: in recent governance research I did with BSci colleagues on resilience in Lido gov assessment, I saw crisis planning/gov documentation from Yearn that was pretty fantastic and made me think developing crisis planning for TEC would be a good idea…

Appreciate any feedback and updates thank you!

Tamara · May 16, 2022, 8:54am

Hi @JessicaZartler!

Yes. Sampo is a new WG that has very recently formed specifically to focus on financial sustainability within the TEC. It is still ramping up. We are fortunate that @gideonro has volunteered to Steward the WG and those initiatives.

Crisis planning does sound pragmatic. Can you share some of the topics covered in the assessment you mentioned.

Also, the vote is now live in the Gardens for Stewards funding for another 3 months.

https://gardens.1hive.org/#/xdai/garden/0x1fc7e8d8e4bbbef77a4d035aec189373b52125a8/proposal/22

JessicaZartler · May 16, 2022, 12:14pm

Cool! Glad to hear it! Thanks @gideonro

Here is the Yearn Emergency Planning Github:

github.com

yearn/yearn-devdocs/blob/master/docs/developers/v2/EMERGENCY.md

# Emergency Procedures for Yearn Finance

## TL;DR: [Emergency Checklist](#emergency-checklist)

## Introduction

This document details the procedures and guidelines that should take place in the event of an emergency situation. Its purpose is to minimize the risk for loss of funds for Yearn's users, Treasury, and Smart Contracts.

## Definitions and Examples of Emergencies

For the purposes of this document, an emergency situation is defined to be:

**_Any situation that may lead to a considerable amount of loss of funds for Yearn users, Yearn's Treasury, or Smart Contracts deployed by Yearn._**

This is a non exhaustive list of possible emergency scenarios:

1. Bug/Exploit in Vault/Strategy code that can cause a loss of funds for users
2. Bug/Exploit in an underlying protocol that a Yearn Strategy is utilizing that may lead to loss of funds
3. Loss of private keys for a key role, such as a Strategist
4. Potential exploit discovered by team or bounty program researcher

This file has been truncated. show original

And overall, they have some of the best governance and operations documentation I’ve seen, so definitely worth a review:

Thanks so much for responding so quickly and the updates!

gideonro · May 16, 2022, 9:52pm

Thank you, Jessica. Still need to dive into this in more detail but it looks very helpful.

We will need to get to emergency procedures.One of the other things is how we proactively steer a conviction-voting based spending process as passing proposals gets harder and harder with a shrinking pool? This is one of the things that’s really got my attention right now. We have a draft high-level strategy that is still very early in the advice process but would be happy to share if you’re interested. One of the key ideas is “capacity building”.

JessicaZartler · May 17, 2022, 9:40am

Hey Gideon, thanks for your message! We can also take to DM or Discord channel where convo is ongoing lmk when you get a channel for this WG set up

Makes sense, also FYI Jeff and I have been having calls with Gitcoin DAO and they are planning to build some kind of Osmotic Funding tool that disperses funds as conviction builds proportionately so that could be an interesting future box consideration - though I am not sure technically how the stack could/not integrate… (you can see this thread for info Dear Moonshot Collective 🌜 Help DAOs Level Up Gov tooling: BUIDL Request for Chain Agnostic Conviction Voting - Special Projects - Gitcoin Governance).

In the near-term - happy to have a look at the strategy (low on cycles atm)… have some meetings this week in Berlin with Trent M, Cem and some other high voltage TE brains - my thought (if you haven’t already) around solutioning for pool sustainability was to gather the best mechanism designers like those guys and Z/Simon DLR/Jeff/Griff/Sebnem/Angela and some others for a TE community brainstorm around this and talk about in general, how to improve on designs/parameter “modes” for various points of the economy i.e. bootstrap phase, ongoing smooth production phase/potential reboots - similar to Temple DAO…

Anyhoo - I am happy to support rallying those folks into a room / Miro sesh when you get there (no rush! I’m quite slammed until mid June, but in person with some this week so I’ll plant the seed…)

Feel free to DM me & I’ll send you my email and I’ll also stop blowing up the budget thread here!

Solsista · June 6, 2022, 10:51am

I can also imagine that opening this up as a learning opportunity - gets more interest and participation in TEC. Especially if it involves the “emergent practice” analysis as Jess offers.

The issue always is the “low on cycles”… What I could offer is: we’re doing a similar exercise for the TE Consilience Library, which is a “fractal commons” in TEC; that we share any insights and potential solutions?

However it is clear already, that if we want people stewarding, i.e. picking up the slack, guiding, signalling on health etc. Then there should be a baseline that does care for those Stewards. Another alternative is that some WGs have insights/knowledge goods that are already useful contributions to the TE knowledge Commons (which in my mind is still what TEC is, commons pool is just a means but not the end of the public good of TE).

However they are low on comms cycles . There we should definitely reuse TEC comms etc. so there are also some baseline internal process optimizations that are obvious but not yet operational for some reason, not analyzed.

So definitely yes to improving proposal engines in this space, and don’t see it as a TEC issue, but an issue of transitioning from “market competition” to a “collaborative commons” mindset - the tools we have do not support that mindset. nor the transition… So a lot to do and learn. I trust that if this was formulated as a learning opportunity and a valueable contribution to TE Knowledge Commons it would get the attention it deserves, incl. token engineers and TEC holders and larger token ecosystem.