2022-08 - E Monthly transparency report

E Contributor report

Overview

Timeframe: Month of August.
Background: Contributions E has made to Yam are numerous from the very beginning of the launch to date, focusing on core developments.
Goals: Pushing yam forward to reach its initial value and surpass it as we progress into the future.
Yams: Vesting over 6 months based on the 30day avg. value ($0.160). :sweet_potato:

Core Development

Comp: $8k in USDC with 12.5k YAM (2k / 0.16).
Work: 80h per month.

Govops / Infrastructure

Comp: 50k YAM (80 * 100 / 0.16).
Work: 80h per month.

Hey E, I would like to see your compensation broken down by project you are working on. How much is Gov-Ops vs Core Development, etc. You can see how I did it for my projects here: 22.09.05- Specific Architectures (Ross) Contributor Compensation Request

404 error with this link

Can you clarify what these bullet points entail?


“Work Done” Structure

While this is ultimately up to you and what is acceptable to the token holders, I would like to see more clarity and accessibility in how you present the work you did. I understand that this is a somewhat vague request so I will show you what I mean. I had to go through and parse out this information. The goal is to make it easy for token holders who are reviewing the work to find exactly what has been done, and the context for it .

This is the level of transparency and ease of finding information that I expect as a token holder.

Thanks for your contributions E! What is your rate you are billing for? What are the hours you are billing for? I see a lump sum here. You have been approved for Gov Ops Council with max compensation 100/h up to 80hrs 100 Yam. Please confirm with clarity on future compensation reports.

Treasury Director Review:

  • Grant not approved (approval for Gov Ops only for month of August)

  • Work incomplete (work being billed for is out of scope and not entirely previously approved)

  • CR Denied

Notes:
Thanks E, while some of this work is valid this CR requires more detail and revision based on the above comments.

1 Like

Thank you for reviewing @jpgs.eth
I will update splitting them to make it easier to follow.

Will be taking in consideration some of your comments @ross, thank you.

This is a half assed revision of what was requested. We have discussed this multiple times on multiple channels. Approved and Unapproved CR’s need to be submitted as individual CR’s not combined. Because we are now delayed a day on the on chain submission (which should have happened yesterday) due to you waiting approval on an ambiguous edit that again bills lump sum 80hrs for 2 line items (core dev and mgmt of repos), this CR is still REJECTED. You will have this entire next month to get your revisions correct, and bill accordingly. We cannot keep playing these silly games and holding hands. This is wasting everyones time and it does not sit well with me nor should it for the entirety of the token holders and Yam community.

Not sure to get what youre talking about @jpgs.eth, you have requested the update here and here, it was updated, and i pinged you about it multiple times for multiple days prior to the last day for you to review, but it was ignored, and now commented on with complete missing points, then we see mentioned silly games and delays. You shouldve checked it at least back then for an adjusted review.

Isnt this already past us? the subject isnt about what was not approved, its about what was approved (govops) which was the part thats supposed to be checked, as per your request, it was updated and separated.

Ignoring my pings and comments for days, rejecting everything that ive been working on after we have both known and supported, then sunday speaking about what should have happened. It is as you said wasting time, and doesnt sit well with me, with you or with token holders. That shouldnt have happened, what should have was cooperation.

I am not purposely ignoring, but it was not clear to me you made any revisions because I expected the revision to take place through a separate CR. Maybe i’m being too rigid in expecting this distinction. Can I approve half of a CR? Seems like not the ideal way to proceed but effectively that is where we are.

In the end, what goes into the on-chain transaction is what matters. Everything we are doing here is to make it easy to understand and vet the work and information presented. I agree that this is still a bit hard to keep everything straight and could be clearer, but the contract reflects what you are asking for.

In the on-chain contract, @ethe has not included payment for this work or last month’s outside of the gov-ops work.

Note the second line is commented out, and the first includes no USDC.

So lets set the standards for what is expected when work is not approved beforehand and make that clear so that we can make sure it is done right going forward. It would be good to have a way to note what was approved and what wasn’t so that we don’t have to go back and forth between different sources. Right now, just looking at this thread it is impossible to tell what was approved and not without looking at the on-chain transaction.

1 Like

Thanks for the clarification. I agree the on chain is what’s important and being able to reference without confusion so now that I have better understanding no need to reject E’s CR because the on chain is reflecting what should be/is approved. What makes the most sense to leave the necessary off chain bread crumb trail for anyone looking back to figure out what happened and why without having to dig too hard? Not sure this chain does it well enough.

The obvious issue is that you edited your original posts without an update to the thread, I am only now understanding what happened because I can see the edits as an admin. You should add a post at the end just stating you’ve update things. In addition, Jpgs said to separate out the requests into what hasn’t been approve and what has been approved, which at the top of this thread is still together in one thread. Confusing.

The template that I originally created for this makes the assumption that the work has already been approved. Whatever happens, in order for work to be paid it must be voted on and approved in a snapshot vote at some point in the process. Separating out the approved and unapproved work makes perfect sense, and this is really what the grant process is.

You apply for a grant to do a scope of work. That gets approved and then the transparency report is a continuation of that process. A transparency report without an approved grant is just an incomplete grant application. E’s grant application is this: E Yam Core Development - Phase #2 (Aug Sep), which has not been approved yet.

As far as a trail of breadcrumbs, there are a few things we can do. The first is that we should insist that transparency reports cross reference the grant proposal and the snapshot vote to approve. When grants are approved (officially approved via snapshot, not just you saying “approved”) then there should be a post in that thread that links to the vote and an update to the grant proposal. This starts with the original contributor simply putting in the effort to make it easy to understand for anyone looking. Updates to the original post should be called out with text saying “updated on [date] to include [stuff]

I should be more proactive in documenting as well. Something that I can do is try to jump in an reserve the post right below a application, transparency report, etc so that it can be updated with the status or other important info. I am going to look at using a table at the top of posts that can have a status too.

I will be posting some new grant requests shortly using a new template that we can review and discuss.

I think everyone can see the updates if they click on the pencil at the top of a post. It shows the number of edits and the changes.