(1) I’m not sure I agree with you on this one. I can see some potencial in a system where community members could seek out projects that they think would benifit CKB and put in the work to bring those projects to CKB acting as sort of a middleman. In this case, I don’t see a problem with that community member or community group submitting the proposal on behalf of the project, I actually think this is the best way as it makes it clear that there may be some sort of link between the groups and nothing is hidden.
(I also just want to say that I have absolutley zero knowledge or involvement with the Palmyra proposal, so this is just my opinion as a member of the DAO)
(2) 100% agree with you here. This issue needs to be discussed more and something put in place quickly imo.
(3) I’m not sure I understand this clearly, are you saying that vote should take place before every installement?
All project applicants must be the executors, and no agent of any kind (including officially authorized agents) is accepted.
Have to disagree on this one. Multiple teams need to be able to collaborate and work together freely without restriction. I don’t see a strong benefit to adding this restriction. Perhaps guidelines for suggested disclosure and notification could be set for edge cases, such as the executor changing hands in the middle of a grant.
The form of DAO’s application funds is US dollars, and the specific form of distribution is CKB at the price corresponding to the time of fund release.
Agree the denomination should be US dollars, and the calculation should occur at a specific time. However, the exact time is debatable. I could see using the time of proposal/milestone approval or the time of payment execution. However, there needs to be a second clause to guarantee that events occur within a specific window of time after the submission.
The one-time execution requirements of DAO application projects should not exceed a certain amount, rather than all being approved at once in the initial stage; at the same time, the approval difficulty will be increased for project applications exceeding a certain amount (such as US$50,000 or US$100,000).
I understand the intent of raising the approval threshold for higher-value grants, but I don’t necessarily believe that low-value grants should receive any less scrutiny.
Lack of accountability and careless approvers who take an “it’s not my money so I don’t care” approach exist, just as you say they do. I always encourage everyone to treat the DAO funds as their own, because they do belong to us. As CKB investors, these are our funds and how they are used can greatly influence the performance of our investment.
In the past, I’ve worked with large corporations and Fortune 500 companies. I’ve been an employee, and I’ve also worked on the other side as a sub-contractor. Everything you are describing exists, but it is not the only possibility, and to suggest so is an oversimplification of business processes.
It is not uncommon for agencies to form and use sub-contract developers. Yes, they take a cut. However, they are taking a cut for providing a service. They develop a network of contractor relationships that they have vetted and then manage projects to ensure success even if some of the developers do not perform or choose to leave. Developers may also prefer this relationship because they can focus on their work without dealing with business process.
I understand that you would prefer, in the most pure sense, that the developer apply themselves and elimate any other party. I also think this is the best scenario, when they are fully capable on their own. However, I have watched this exact scenario have very poor results far more times than I have seen it succeed. Usually the project fails because the developers were good at writing code, but not at marketing or business development.
When evaluating a DAO proposal, we should be looking at the qualifications of the team, the value provided by their ask, and the accountability that is built into the proposal. It is far outside of the scope of the DAO to restrict how teams should be structured or operate.