Mandatory Updates for Verified Projects

GIVernance
1

We’ve discussed this topic in the previous strategy session and in a past forum post.

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.

Concept

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.

Nice-to-haves/Future roadmap items

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.

Unanswered Questions


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!

6 Likes
2

Yes Mandatory Updates! I think the simple value of forcing projects to come back to the platform and keep their project active will add immense value to donors. However maybe we should zoom out and look at the value vs. cost of policing updates.

If you want to move away from subjective and centralized verification processes maybe we should question how moderating project updates takes us any closer to this goal.

Optimistic Update Moderation

Perhaps we build some sort of optimistic update moderation, where we assume all project updates are well intentioned, removing the requirement for individual review/approval and have an open signalling system for users.

Each project update, once posted could have three options under the heading “How informative was this update?”, users, other than the project owner, can respond with “upvote”,“downvote” or flag/report.

We can go further and set metrics to keep project moderators informed with minimal overhead. We could say that if a project update has over 75% downvotes with a minimum votes of 5 then a flag is sent to the project verification team, if a user flags or reports then obviously a flag is sent as well.

If the update is malicious or breaks our terms and conditions we de-list or cancel it. If its a bad/uninformative update we send them an email.

If a project games the system and provides garbage updates and/or “upvotes” themselves via multiple accounts it really doesn’t provide any clear benefits for them. Other users can see the project posting uninformative/bad updates and using their discretion, will simply not donate funds.

Going further, if we choose to incorporate project updates into a project ranking system we could say that any updates above the downvote threshold are disqualified, meaning the project is ranked as if that update never existed. We could also allow project mods to manually disqualify updates as well.

Hopefully these are helpful ideas, I think the end goal as I understood is to reduce the overhead for project moderation as giveth continues to scale. Let’s try to keep scalability in our focus and avoid becoming the project police.

7 Likes
3

Whoop whoop - update or fall down in search engine! We don’t have to create any special activity feed section. Can we implement “activity recognition” into our search engine by default instead?? That way only project with regular activity would come up at the top of the projects page?!

This could be easy. I did some math and went to look into actual statistics. Out of the first 115 Givingblock projects, only 17 of them actually received donations via our platform. That makes about 14%. Looking even deeper into that, I found that mostly we talk about 1 or 2 donations at all within the last 6 months, and 90% of those donations come from one and only donor - David Wisner. Seeing this - I would feel totally okay with simply revoking their batch and just keeping the Givingblock integrated on the platform if it helps to maintain good relations with Givingblock.

Maybe something like this can be a solution:
We can start with building a new update section with required components:

  • A project must upload media (picture or video, it can be also a picture of receipts) and must provide a description. For example:
  • Describe what is in the picture.
  • Describe how did it help on the way to reaching your goals?
  • What are the next steps? (optional)

If we can make these obligatory requirements it can help us not only to inform the project owner about what we are looking for but also can help prevent nonsense inputs.

I really like what @mitch wrote about the ranking/upvoting/downvoting/report system. If users had an option to like/dislike/report the update, we wouldn’t need so much policy around the review. And maybe this way the quality of updates would regulate itself. Same as the ability to comment under the update.

Those are my two cents. :slight_smile:

Thanks @WhyldWanderer for your consistent work on this topic!

3 Likes
4

If a project posts photos they should be authentic and genuine photos. There are examples of projects on the platform that have submitted photos obtained from the internet - I feel strongly that this should not be allowed as it is misleading.

Direct links to any external reporting can provide detailed and useful information, if a project already submits this type of information. Direct links will make this info easily accessible, then it’s the decision of the donor if they choose to read or not or whether they value this kind of information.

3 Likes
5

Thanks @WhyldWanderer for all the work that has gone into this proposal and its predecessors.
Thanks, @mitch for some really good ideas around decentralising the quality control. I love metrics and the voting categories make sense to me. Imo this solution will not eliminate the possibility that a ‘rogue’ project can get upvoted by the community but it would provide a good safety net. Giveth should consider having a disclaimer on the page that donors should carry out their own due diligence before donating.

1 Like
6

Thanks for this great post!
I agree that project updates make sense for projects to keep their “verified” status. At the same time, we should keep this as light as possible both for the projects and us.

A few ideas:

  • I think updates every six months is enough (+2 week grace period).
  • We could have these six months start only after a project has received its first donation (or after a project has received more than $100 in donations). Projects might be more motivated to provide good updates once they have benefitted from the platform.
  • We should communicate from the start that the verification status “automatically expires every six months” - instead of “revoking” something.
  • We should not require updates on actual social impact from projects. This is too high a bar, and projects will invent all kind of nonsense. A thorough look at impact from our side should happen during the verification process (separate discussion). Here, light activity updates are sufficient (“last week we had this event…”, “this is our new teacher in our school…”, etc.). I like Nikola’s list and the requirement of an authentic picture.
  • I like Mitch’s up/downvoting function. If it is too much of a development effort, we could start without it and see what happens.
4 Likes
7

From donor perspective, I love this idea and would so appreciate having a way to provide feedback to projects on the quality of their updates.

From project owner perspective, two things that have come up from posting updates:
#1 - there’s no warning right now that when you post an update, your project basically disappears from the Giveth project list until it is reviewed. New project owners frequently think that either they did it wrong, the update didn’t work, or there’s a bug in the system.

#2 - only the project owner that holds the keys to the kingdom (access to the wallet) can post the updates. I know this has been discussed extensively as a feature to add in the future, but I don’t know the status of this requested change. In order to get updates posted in a timely manner they need to be able to delegate the task to someone who creates media / does storytelling, which is often not the person responsible for managing the funds.

5 Likes
8

Thanks for raising the issue, we will fix this asap,
by editing the project, we should unlist the project, but when user just shares an update, the update shouldn’t be listed until it is reviewed. we also let users know that the update will be published when it’s reviewed.

4 Likes
9

I think @rainer.hoell shared some good points!

but here is what I’m thinking:

  1. updating every six months should be the requirement, but we also have to think about ways to encourage project owners to share more than every six months!
  • We can give users a badge for posting more updates to let their project catch more attention from donors!
  • We can reward them for posting more updates.

If users share more updates it will make projects more attractive for our donors and also make the platform more alive.

2 Likes
10

I think activity will definitely be one of the metrics taken into consideration for ranking. There is a forum post about it here: Project Ranking Metrics

I still think that in order to remain ‘verified’ the project should be required to show activity in order to remain current participants in the GIVbacks program.

4 Likes
11

I love this!! I will talk with the devs of how we can implement this system… its useful for decentralizing project verification as well as updates and unliting/unlisting etc. We need flags!!

in the meantime, I think that manually reviewing the update is not too much overhead at this point. Giveth only has 158 verified projects if you don’t take The Giving Block projects into consideration.
Nikola and are are already in there doing listing and unlisting and I think this is manageable so that we can start having some sort of requirement - we have quite a few of inactive ‘verified’ projects and I believe its best to start implementing something that is safe enough to try.

2 Likes
12

After reviewing the feedback on this forum post and within the governance calls, I have determined the following for the above unanswered questions:

The Giving Block projects will be immune to mandatory updates for now.
Following discussions with TGB’s team and current GB project owners, we will have be able to come to a final decision on the future of these projects and our partnership with TGB.
Until then, these projects will maintain their verified status.

Must include:

  • some form of media evidence (unique photo, video, invoice, etc.) or links to media evidence
  • short description
    • what is in the image or media
    • how it is helping to solve a problem
    • what are the next steps (optional)

We should have a way to reject the update and trigger an email to the project owner until we have a flagging system in place.

2 Likes
13

Yes!! In the spec document linked above, you can see that a activity page/section is part of the roadmap. This will need some help from design btw :wink:

Maybe this is a page linked at the top of Giveth:
image

Or in a section on the Projects page somewhere.

This will encourage project owners to stay more active and keep their projects close to the top of the list of latest updates… which will bring more donors.

1 Like
14

I hear the above statements and would like to share why I am still choosing to go with quarterly updates as described above.

  1. Its very easy and minimal effort to add an update
  2. The GIVbacks program is just over 6 months now… which means that, with the suggested grace period, we would not have required updates thus far in the program. I believe that there is current evidence to support that we have not seen enough activity for our current verified projects thus far which would indicate that we want to see something more frequent than every 6 months.

If we notice that projects are having a hard time reaching this goal, we can reconsider lengthening it at that time.

3 Likes
15

Processing, not too much feedback but wanted to add my support:

  • I like quarterly updates.
  • I like mandatory updates and verification status « automatically expires » instead of the « revoke » approach. Two sides of the same coin but with a both positive and proactive spin.

Super amazing feedback to everyone on this thread!!

2 Likes
16

I like quarterly updates as well. 4x a year someone has to write a paragraph to keep their donors in the loop? seems like a pretty low bar.

I really love @mitch’s idea of optimistic update moderation, but also agree that we should get this live w/o it first… Coordinate w/ devs to get some time estimates.

Thanks @WhyldWanderer for kicking this discussion off, making it so clear & organized & to everyone else commenting for all the hugely valuable feedback. Our forum is a magical place.

4 Likes