Closed JuankBell closed 3 years ago
[MrsBadgerface] Hey @tamarandom Much appreciation for how you've broken this down so clearly. I can see how the current system seems to be set up to dis-favour the very people that give it time and care and I can see the sense from a systems change perspective of nudging where we're at with simple, clear small steps.
[danelsuga] Thank you, @tamarandom, for this great and meaningful effort to modify a broken system without being too disruptive. Were we able only to wish that the radically anti-traditional-establishment MVV of the TEC based on equality and inclusion could accept more (of what's best for the commons)! ❤️
[sembrestels] A decision not to intervene in a system that, unintentionally, resulted in some serious flaws that are bad for our Commons feels like the antithesis of an engineering spirit. “It’s broken but don’t fix it” does and should create a cognitive dissonance.
Unfortunately, there are many times that we face problems that is better not to fix, because fixing them create greater problems. In this talk we can see Andreas Antonopoulos giving an example: even changing three lines of code in the bitcoin protocol to fix multisigs is worst than the problem that they cause. The talk was given in the context of the Bitcoin / Bitcoin Cash fork, and in some way it resembles the current discussion.
[LinuxIsCool] To summarize this intervention:
1.For future praise - create a fixed 4% IH allocation for re-tweets and attending meetings. This would make a re-tweet worth roughly 0.09 IH and attending a meeting roughly 0.2 IH
2.Return 40% of deducted impact hours back to the workers
[Jeff-Emmett] A decision not to intervene in a system that, unintentionally, resulted in some serious flaws that are bad for our Commons feels like the antithesis of an engineering spirit. “It’s broken but don’t fix it” does and should create a cognitive dissonance.
Unfortunately, there are many times that we face problems that is better not to fix, because fixing them create greater problems. In this talk we can see Andreas Antonopoulos giving an example: even changing three lines of code in the bitcoin protocol to fix multisigs is worst than the problem that they cause. The talk was given in the context of the Bitcoin / Bitcoin Cash fork, and in some way it resembles the current discussion.
Not fixing this problem also comes with it's own dangers, @sembrestels. Among them:
deterring Token Engineers from participating in a community economy that doesn't value their inputs or labor unabashedly dismissing necessary algorithmic policy steps (e.g. critical analysis of output data) in the interest of protecting the privilege of a few large token holders (who were the beneficiaries of a skewed IH distribution process) relegating the TEC to be as oligarchical and inequitable as legacy protocols, despite the community sentiment to "end the technocracy". What I am most interested to see in this process, is whether the TEC is willing to walk its talk... Great proposal, @tamarandom!
Hello! Might I ask that whoever put the flying cash emojis on this proposal title please remove it. This is very much not the intent of this proposal and it sends a very misleading message. Thank you.
Sorry! Fixed it
I want to show appreciation for this proposal.
I agree with Tam that doing nothing doesn't ring true to the mission of the TEC. There is a broad agreement that the system as it is has severe issues. Since we still have time to do something about it we should try to amend it somewhat, or at least attempt some damage control.
On the other hand, of the solutions proposed, I think proposal #11 misses an important point: Even if binding voting power and remuneration together has proven to be a failure point, and even if this distribution method was supposed to be experimental, it has nonetheless been the agreement under which people have been working and making economic decisions for the last several months. Yes, it should have been designed differently in the first place, and yes, there should have been an earlier analysis that would have raised red flags. But radically and retroactively changing the rules of the game shortly before it ends is not good governance, nor does it set a good community precedent. After all, the system was not maliciously exploited, it only happened to be a flawed design.
With that being said, I like how proposal #12 tackles the biggest pain points head on, but I fear it may bring trouble down the road. At the center of the TECommons design is this bonding-curve-based tokenomic system, with its unique interplay between voting power, dynamic mint/burn, tributes etc. It is the engine that will power this organization, which is supposed to lead by example in advancing this new field of engineering. Adding a group of completely new, special voting tokens which are conceptually separate but will be forever "tacked on" to this engine, and then give them to a hand-picked group of contributors to balance out "issues at the initialization phase" feels un-engineery, and maybe even like compromising a part of why we are building this in the way we are.
I like griff's idea of giving big praise contributions to those whose work ended up underrepresented: since the system as it is in place right now can be used to address and correct these inequalities, let's just purposefully do that. The hard cap on retweets and meeting valuation this proposal suggests for future quants will also help "grow the pie" for those contributions.
In summary: since we are between a rock and a hard place, this proposal seems to me the most graceful way to sunset a reward system which has shown itself to be deficient. We all agree that it will have to be thoroughly redesigned in the future, and I personally like some of the ideas showing up in #11 very much. There are fascinating discussions to be had and cool models to be designed. But for now, tweaking the % of IH reduction after having assessed the data seems like the least disruptive way to honor the expectations built, show goodwill and signal intent to change, while still maintaining the structural integrity of the Hatch and all the processes that have been driving towards its construction.
I agree @PabloCGL . I think that this is the most reasonable and TE style proposal in the run-off. Unfortunately it's clear that it is not going to pass, and I would like to propose that we close this proposal to free the re-allocation of votes.
Thank you @PabloCGL and @LinuxIsCool for seeing and appreciating the intention of this proposal. That means very much to me.
Praise Analysis Dashboard
1. Does this proposal address that some categories may be under rewarded and others over rewarded?
No retroactively / Yes for future praise quantifications
2. Does this proposal address that paid contributors have had a 50-85% reduction to their total number of impact hours?
Yes
3. Does this proposal address that foundational members of the Token Engineering Community may lack recognition for their less visible work?
No
4. Does this proposal address the distribution of impact hours in relation to equality metrics such as the Gini Coefficient?
No
Preamble
The majority of us are not engineers but we are collectively undertaking this mission to advance a novel and nascent form of engineering that we all believe has real potential to create a more ethical and just world. With that in mind, I thought it worth sharing the Engineers’ Creed. The longer Code of Ethics is good too but the Creed is nice and concise.
As a Professional Engineer, I dedicate my professional knowledge and skill to the advancement and betterment of human welfare.
I pledge:
A decision not to intervene in a system that, unintentionally, resulted in some serious flaws that are bad for our Commons feels like the antithesis of an engineering spirit. “It’s broken but don’t fix it” does and should create a cognitive dissonance.
What interventions are being proposed?
Does this proposal address that some categories may be under rewarded and others over rewarded?
Not retroactively but going forward, yes, I propose the following as an immediate solution. We have a set percentage of total % of IH for retweets and for attending calls.
What does that look like? It’s a very simple solution that can be implemented in the next Praise quantification. Let’s take an example,
We say:
We have:
That means:
Why am I not proposing a retroactive intervention? The data set, like any data set not designed with future data analysis in mind, is not clean enough to do this in any legitimate way I can see other than going back and manually inspecting each praise and tagging into a category. To undertake this will require agreement on categories, category weights and then the herculean effort to manually inspect much if not all of the data set. The possible results do not merit the time or effort that would be required to do this with a sufficiently high level of quality.
Does this proposal address that paid contributors have had a 50-85% reduction to their total number of impact hours?
The root problem is that Impact hours are being conflated with compensation. Praise is designed to promote a culture of gratitude and to showcase invisible work. It works very well for that. We see clearly the model break when employed as an alternative compensation method.
As Griff underscores in #2 : “This is bad for the Commons, these contributors have a deep understanding of the inner workings of the system and how things evolved to get to launch. This context is very valuable for the DAO to have when voting on proposals, especially related to DAO operations and upgrades.”
I am making this proposal intentionally modest in the hopes that the Stewards, active TEC Community and wider Impact Hour and CSTK holders will recognize that doing nothing is indeed a terrible decision for the TEC and that a modest intervention will be palatable enough to see this intervention passed.
The proposal is to restore 40% of deleted earned Impact Hours.
What does that look like?
These are the contributors that are impacted.
Conflating monetary value and governance power is, of course, the glaringly obvious oopsie but hindsight sometimes works like that. Ok. Fortunately, there is one opportunity to now correct for the uncovered flaws in the model. That it wasn’t inspected or this wasn’t well thought through before is not a reason not to fix what's broken now when the opportunity presents itself. Even if only in a minor, token way being proposed here.
Then there is the question of the dubiously wide net cast. For example: Griff, Livia and myself are very active in the day to day of the TEC. If there was ever any reason to justify deleting 85% of IH, it could be made for us but Jeff, Dan and Kris have full time jobs and full time work at Commons Stack and participate in the TEC not because it is part of their job but because they want to. Just like all the other contributors here who are receiving their full earned Impact Hours.
My proposal does not address this individual by individual like Livia’s #3 because I am favoring simplicity with one action applied to all impacted. Whether, when and how deductions should be applied going forward is a discussion outside the scope of this proposal but a commitment to those future discussion does not absolve one of the responsibility to act now.
If you’ve gotten this far, 🤗 thanks for reading!
What is the reasoning?
(reasoning included above)
🤔 Take a look at this forum post if you have any questions.
🗳 When you are finished writing, head over to TokenLog and vote for your favourite proposals!