I have created this post to collect community answers to some questions that came up while developing the structure for mandatory updates. It is important to keep in mind that the intention is to fill a gap that has been created as we attempt to move away from the hard/centralized verification process. The intention is not to use energy creating a complex verification process (which at times is subjective) or developing rules on how a project should report impact or update donors. We should instead focus this energy on creating a system for ‘decentralized project verification’ through curation and ranking.
Meanwhile, we have realized that there is a need for requiring projects to prove that they are active and using the funds for what they say they are in order to stay enrolled in the GIVbacks program. This is the gap that the ‘mandatory updates’ concept is looking to fill.
All verified projects will be required to submit quarterly updates in order to keep their verified status. In our messaging we should always encourage ‘regular updates’.
We can set the expectation of quarterly updates and allow for a 2 week grace period (104 days in total).
If they have gone:
60 days without an update - send a reminder email (friendly reminder)
90 days without an update - send a warning email (you will lose status)
101 days without an update - send a last chance email (only 3 days left!)
104 days without an update - revoke verified status (your status has been revoked and you must reapply)
We will need to inform current Makers as well as add this information to the verification user flow so that users (current and future) are aware of this requirement.
We will need to implement a technical flow for triggering emails to project owners as well as draft the email content.
- Segment events
- Autopilot journey
We will need the functionality that changes a project’s status from ‘verified’ to ‘revoked’ upon reaching 104 days without an update.
We will want a page to showcase latest updates - An activity feed section on the Giveth site.
- This can be a page of its own or a section of the homepage.
We will want for users to be able to comment on updates.
- This is already on the Development roadmap.
What happens with Giving Block projects? They aren’t able to add updates and therefore would lose their verified status upon implementing this system.
There are current discussions happening…
Some think that we should remove the Giving Block projects altogether - there is discussion here.
Griff talked with some of the Giving Block people while in Austin. They will not be able to give us contact information for projects due to legalities, however, they said they are willing to work with us to facilitate a better partnership when it comes to communicating with projects… Lauren and Ashley have a call with someone from the Giving Block’s team to discuss this facilitation.
Melody and Ashley will have a meeting with one of the Giving Block project’s owners soon. They just realized that their project is collecting donations on our platform and want to get more involved. We see this as a great opportunity to explore the options when it comes to transferring ownership of Giving Block projects.
What type of evidence should we ask for? What does an ‘approved’ update look like?
I’m unsure of how to answer this. I do not want to be too rigid and I also want the project owners to have a clear idea of what is expected of them. We can use examples to show the difference between updates that would be accepted vs updates that would not. I really think this will evolve organically once we start… We will get a better idea of what types of things people are submitting and we can go from there. It is relevant to keep in mind that future curators should be able to easily access any evidence submitted by projects in order to curate accordingly. I.e. they should not have to check a government website for budget reporting or impact reports.
What happens if a project submits an update and that update is deemed to be insufficient to maintain verified status? I.e. not enough evidence provided in the update
The team will need to review each update just as we review each edit made to a project. If we review an update to a verified project and it doesn’t meet the requirements to maintain the verified status, how should we proceed? It’s not really feasible to manually contact each project owner. It also doesn’t feel right to revoke the badge and make the project owner re-apply. Where is the middle ground?
Please add to the discussion here around these questions. I am hoping that we can have some answers in the next week so that we can start implementing this process. It is a bit overdue. You can refer to the spec document here.
Thanks in Advance!