Whilst the Unlisted and Listed terms work for the project owner, I feel a Listed/Unverified status could work also for the user and a CTA for the owner to get it verified.
2 Likes
Listed/Unlisted Guide (in progress): HackMD - Collaborative Markdown Knowledge Base
Please feel free to add comments/suggestions
Notes from our idea generation meeting:
Livestream of the discussion: Giveth livestream - Giveth.io Resilience on August 25, 2021 - YouTube
The plan is to move forward with creating the listed/unlisted layer on giveth.io next week. Comms team to work on imrpoving the guide, and write notification emails to projects that will remain unlisted (or will get cancelled).
Love the action and updates! PRAISE!
I am also a fan of unlisted, listed and verified… it also seems like there may be need for “censored” like the Malicious dappnode campaign…
I’m not happy about it but in the end I think we have to accept that people do stupid stuff on the internet and we can’t host it on our website… SHAME! SHAME!
How strict we are about it should be explicit with a terms of service, and i know Lauren and others are working on it… PRAISE! PRAISE!
Love this thread.
BOOM! That’s what we’re moving forward with.
And then we also will just censor projects as well right, if they violate the terms of service?
I think we must, when censored it should be removed from the public view and notification sent to user email informing them about the violation. Violation email should be a template we create that is sent automatically from server when master admin removes a project.
If there isn’t an issue open for this already then I suggest @MoeNick @mateodaza to create one. Copywriting do be done by someone from Comms team @karmaticacid
1 Like
Yeah! We talked about this with comms already… We’ll draft two emails
- One to explain the project is going to stay unlisted and asking the owner to add info.
- One to explain the project was cancelled because it violated the terms of conditions.
@MiA and @Danibelle are also working on updating our terms & conditions which will the ground for which we cancel projects.
Comms is also reviewing the listed/unlisted guide for project admins who are going through and doing the manual choosing work.
1 Like
Following the implementation of the unlisted/listed system we’ve encountered some discussion over whether the default status of newly created projects should be listed rather than unlisted.
These are some remarks I heard during the DEV call 18/10/2021. Please feel free to add.
-
If we choose to make projects unlisted by default we should add something into the front-end, immediately, that explains this new flow and new statuses.
-
We have a team that will be dedicated to checking projects as they are created, we have tools that will allow us to do this with minimal overhead
-
Project owners shouldn’t be penalized or disempowered until proven to not meet listed criteria
Also we can refer to this github issue for further context - https://github.com/Giveth/giveth-next/issues/303#issuecomment-945132365
I’m re-activating this thread to continue discussion on this particular topic of the default status being listed or unlisted upon project creation. In 1-2 days I will create a poll for soft-consensus and hopefully we can move forward with necessary technical changes resulting thereof.
2 Likes
I support: not having unlisted feature at all, however I know we implemented it, so let’s change the default to listed. It’s a natural behavior of an open platform.
And I do not support adding more status there: not reviewed, reviewed and listed, rejected and not listed, rejected but requested to review, reviewed but still unlisted, don’t have time to review so listed, listed from admin dashboard… See?
According to software architecture, we have to limit statuses and add them in standard way to prevent the spaghetti coding. The usual method is adding status with another field : “status reason”, like CRM systems.
Even if we add tags, we may also have further requirements how to change them and maybe someone set a business logic on them someday…
My friends, listing and un-listing is not a matter at all, we only can show 5 -10 projects in our home page, up to 20 in 1st projects page, it can easily be filled with good high score projects. we have to play with sorts and views instead on adding new statuses and operations…
So… first things first, will be great to get the dashboard on live soon. I heard that it’s almost ready to go, needing testing on staging and Carlos is working on setting up emails.
Next, @WhyldWanderer had a meeting training the verification team today, I think the best way forward is to have this team also be responsible for reviewing new projects that get added. Maybe even having it as a weekly or every-other-week hack session? Could be put on the calendar to allow for others to join & support.
And then, this is what I think we should do:
- Projects are added w default status “unlisted”
- We add something to the frontend so the user is informed immediately when adding their project
- Project review/verification team has a weekly hack session to review projects on the DApp and list them
- Add feature to automatically list projects if they are not reviewed for 2 weeks (or we can make it a month, if that’s better).
This is good because:
- It ensures that projects on Giveth are not violating terms & conditions… we don’t end up having projects like “KILL ALL THE BABIES” showing up all over the DApp from Trolls or malicious parties
- It protects us from human error / inefficiencies in our centralized review method
- It informs the user (fairly) how their project will appear
Everyone is in the know, everyone is treated fairly, and Giveth maintains professionalism.
1 Like
I am a strong advocate of projects being listed by default.
-
Its very disheartening to create a project and then try to look for it and not find it on the DApp. People have been creating duplicate projects because they cannot find theirs.
-
Project owners are getting confused between applying for verification and getting listed. They are filling out the application thinking that they are applying to get listed. We now have ‘verified’ projects that are not listed.
-
Innocent until proven guilty is much better than penalizing good projects.
-
According to the roadmap, we will have a flagging feature in the future that allows us as well as users report a project.
-
We now have team and will soon have a dashboard and streamlined process that will allow us to unlist any projects that don’t meet the requirements. Also, we are notified in the #givethio-event-log channel any time a new project is created so it shouldnt be too hard to keep up with unlisting.
2 Likes
I have oscillated between camps on this issue. I see there’s a lot of immediate confusion created by the implementation of this system because we hadn’t thought of how to effectively communicate this to users. We’re now scrambling to find resolutions in real time which kinda sucks and creates tension as the amount of frustrated project owners pile up…
I see the justice in making projects automatically listed and that would alleviate much of the confusion from users trying to make projects.
Reflecting however on how other open platforms (namely digital marketplaces) deal with these sorts of things. I do see very commonly a review process before ‘listings’ go live that protects buyers (or donors) from scams and protects the organization from the legal implications of hosting a potentially malicious entity.
I can think right away of adding the notifications on the high 5 page and somewhere at the beginning of the create a project flow about this “review” process.
I would also remove the project created email from the user flow to remove the notification overhead.
I’m open to either solution but I would make those suggestions if majority rules for projects stay unlisted upon creation.
That being said we need to implement something quickly!
3 Likes
Following the discussion today in the DEV call we have to decide on a course of action for project status’ upon creation.
What should be the default status of a project upon creation?
- Listed
- Unlisted
- Abstain
0 voters
I’m sticking with my original vote for projects to receive their URL so they can share it, and wait for approval to be listed.
I think the decision to start unlisted is a good one, it’s the implementation that is falling short.
If the message that pops up says “Your project has been submitted for review, you can check your status [here] and share your link now to begin soliciting donations”
And an email is sent that says this, along with a map on the User Guide that shows the steps:
LIST YOUR PROJECT
- Create Project (you will receive a link that can be shared, but your project will not show up until you…)
- Share the link with your community to raise funds
- Get Listed (make sure your project meets these criteria to be listed on giveth.io)
- Receive even more Donations!
VERIFY YOUR PROJECT
- Fill out this form…
- Attend a call or introduce yourself in the #verification-channel on Discord…
- …
MAKE YOUR PROJECT TRACE-ABLE
I want to share some of my thoughts and feelings around this decision while keeping focus on the goals and mission of Giveth and the Future of Giving that we are building.
Being steward of the community support working group puts me very close to users - helping with onboarding, project creation, verification, hand-holding and really getting to see where users are struggling while using the application. Since we have implemented the listed/unlisted system and projects start as unlisted upon creation, users have been very confused… If the process is not intuitive enough for the average user, it doesn’t matter how awesome our dashboard is or how on top of the process the team is. So I think the key is that we clearly communicate to the user of what to expect and how to proceed and if we need to make adjustments to mediate user confusion, we should do so.
Keeping in mind that Giveth’s first ‘Value’ is decentralization, by having a ‘review system’ in place at the very first step after project creation, we become a centralized platform. In the future, project curation will take the place of project verification, giving all users the power to verify projects using GIV tokens. How will listing/unlisting be taken into consideration once we have implemented project curation? How will we decentralize listing/unlisting in the future? I realize a lot of these details will be worked out as we go and we dont have a clearly defined way of how we plan to implement this process. However, these are things to keep in mind as we make these decisions and move toward being a completely decentralized community.
2 Likes
I think that if we are to decide to have projects listed by default it would be important to also immediately implement:
- a system of “flagging” (so that, in a decentralized way, projects can be brought to the attention of admins by any user)
- a disclaimer on unreviewed projects saying “this project is pending review and has not yet been found to agree with out terms of use” (or something like that)
- a clause in our terms of use protecting us against the implications of “bad” projects
- an organized system for our reviewers to review new projects
I think Ashley you have a really good handle on the user’s needs. My main concern with immediately listing the projects is the implications of having malicious, violent or otherwise harmful projects getting listed on the DApp right away, but if we add in the above, I think we’re covered.
Even still, I voted abstain… would love to see more discussion.
2 Likes
I fully appreciate your position Ashley, and have been on that side of this fence most of the time, holding the decentralized/uncensored view of all projects showing immediately and only removing those found to violate the Terms of Use.
My mind was changed at the advent of the token economy and seeing the ‘bad actors’ popping up so frequently - it felt like we made it TOO easy to create a project and thus to create a fraudulent project.
Re Flagging:
It was my understanding that the listed/unlisted curation process is a temporary one, because it really can’t continue to be a manual process for very long. Once we have “flagging” implemented the need for starting out unlisted would also go away, but I understood that to be further out in the roadmap.
Re Unreviewed Disclaimer
This is another viable option, and I can see possible variants as well - perhaps we limit them from the default view, and you have to go to the Search Bar and choose “New/Unreviewed Projects” to accept the disclaimer and then see them.
Re Terms of Use Clause
It’s quite well covered by the Terms of Use already.
Organized Review System
It would be very nice to have a Transparent review system where anyone can go see the list of projects created, listed, verified and Trace-able in the future. Maybe in the future we can explore using Kleros’ Token Curated Registry (TCR) Service to go wide on the Decentralization and engage with ecosystem partners more; this is what CLR Fund uses.
I Haven’t changed my vote yet; but with a few tweaks like how/where they show up in the Project list you can probably get me there. I do want a clear process with easy instructions for project owners on how to create, list, verify and trace projects.
1 Like