I want to try and better explain some of the ideas I have been talking about over the last few months, including re-thinking some of our assumptions about structure of YAM. I have spent time on an exercise where I try and strip YAM down to as simple a structure as possible that still works. In doing this, we have to make some assumptions about what is necessary for the organization to run.

The goal of YIP-100 is to increase accountability of contributors and implement a model that can scale both up and down with YAM as needed. But I understand that there is some work that has to get done, no matter what, for YAM to operate. I envision these tasks as YAM's "Minimal Operating Requirements" and they include reviewing contributor compensation requests, creating transactions to pay contributors, reviewing on-chain proposals, maintaining the DAO infrastructure (discord, website, etc), and a certain minimal amount of communication with YAM holders. This is all work that typically has a defined scope but tends to require day to day knowledge of what is going on. The goal here is the pinpoint the minimal work that is needed and then consider whether this scope of work should be approached differently.

For Example (time spent is a guess):

• HR Group spends 2 days a month reviewing compensation requests.
• Core developers spends 4 days writing and reviewing the compensation contract that is deployed monthly (less if just a multi-sig)
• Core Developers spend a few hours on other, non-payment smart contract work review (but does not do the actual coding).
• Core developers also make sure that the website, discord, etc are paid for and running well.
• Community Liaison Group answers community and contributor questions and coordinates on keeping communication infrastructure up and running. This is not marketing, but minimal communication, coordination, and moderation.

This is the mundane work that most people don't find very exciting, but has to get done. In a way, we don't care who does it as long as it is on time and correct.

The members of the above groups probably overlap, and if they are also part of the HR group then it is hard for them to be held accountable in the same way that other contributors may be. It makes sense to me that they are ultimately held accountable by token holders, and each other. We have talked about using coordinape before, and this seems like a good place for it. Token holders can pay these groups a set amount each month based on hours put in per group and then that can be distributed among those contributors via coordinape.

Here is a figma Jam file with these ideas mapped out. “Simplified Overall Processes and Flow with F.A.R.M Cooperative (v2)” is the most current diagram.

https://www.figma.com/embed?embed_host=notion&url=https%3A%2F%2Fwww.figma.com%2Ffile%2FhwbjkUN3htodItfP7n4nzQ%2FMinimal-YAM-Structure%3Fnode-id%3D0%253A1