Require review of a project before it gets published

[aawiseman]

Is your feature request related to a problem? Please describe. Right now a lot of projects get published that have unclear instructions, have the wrong imagery selected, have squares that are too large, and other issues that lead to bad data.

Describe the solution you'd like I think there should be a required review by someone external to the org that sets up the project to check for those things. It could be a member of the Quality Control Working Group or a HOT Validator for example, and we can have trainings for what to look for so it's consistent.

Describe alternatives you've considered We could skip this step for urgent projects too.

[aawiseman]

Hi all, the Quality Control Working Group would like to prioritize this one

[russdeffner]

related to #2961

[petya-kangalova]

Notes from Tasking Manager Meet Up discussion. @russdeffner @Ichchhie @ramyaragupathy feel free to add to/ edit if I have misinterpreted anything.

As opposed to a requirement, more of a could review crowdsourced approach Discussion on when the review should take place: before or after publishing the project. Proposed suggestions are for after a project is published: [Russ] RSS Feed [on Slack? directly in tasking Manager #2961] so that people are notified of new projects, can review and message Project Manager if any issues to fix [Ralph] Settings-> Notifications: ensure Project Managers get notifications from questions & comments section. Now it is to the Project Manager to enable the notifications

[aawiseman]

@petya-kangalova I think it should be a requirement at least for new organizations or new people who have not yet posted a project. In the past I think that optional, crowd-sourced things have not been effective -- such as preset restrictions or coming up with a vlaidation plan for each project.

[russdeffner]

I tend to agree with @aawiseman that some things have not been effective; and we should look into the why regarding each of those - probably outside of a github thread. My main concern is that HOT likely does not have the capacity to review every project, even for just new organizations because we're trying to do that as part of our on-boarding and that also isn't working. So I would like to believe the more open method of review would be more successful.

[petya-kangalova]

hi @aawiseman thanks for the response. I think then this is a non-technical question to be discussed on who the responsible people for review will be - @russdeffner might be able to add. If there is an agreed plan on how that would work, then we can work on the technical implementation.

Hence, in the meet up, we were trying to at least suggest alternative solution to at least try and see if that helps. And also the responsibility for review does not fall on 1-2 people.

[petya-kangalova]

@russdeffner realised we were typing at the same time! Thank you for the above response.

[aawiseman]

@petya-kangalova @russdeffner I agree, I was thinking letting HOT Global Validators be able to approve. Personally I think it's fine to make people wait -- if they don't get reviewed the PM can ask on Slack for someone to take a look and get some feedback that way. To me it should be on the PMs to make sure their projects are good first, rather than have to rely on someone else to come along later, after bad mapping has happened, to say "hey, your project instructions don't make sense and are causing bad mapping." If it's an urgent project we could skip that, but for most projects I think having some delay would be fine if the PMs plan for that and don't expect projects to immediately be live and mappable.