You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Resolving pages that have been marked bad works okay as long as the PM or a PF or squirrel takes care of fixing them.
Current process: If a project has 10 pages marked bad by 3 or more proofreaders, the project is marked bad and removed from the round. The PM gets an email for each page marked bad as it's marked bad.
The PM can then let it sit in the bad project state, fix the bad pages, or pull it to Unavailable.
If a project has 1-9 pages marked bad, the PM gets notifications when the pages are marked bad, but the project is not moved to the bad state, and sits in the round until someone does something about it.
As far as I can tell, PMs and PFs cannot do anything but move the project to unavailable, or back to waiting, or fix the bad pages. However, there is no block to keep a site admin from skipping a round if the project was marked bad and then moved to Unavailable.
No squirrel worth their salt would actually deliberately do something like that to a real project, but might do so accidentally. The question is, how should we be dealing with bad pages differently?
It's probably not enough to just mark the project bad. The transition from available or waiting to unavailable should be allowed if there are bad pages, but a transition from any waiting state to any available state should not be allowed if there are bad pages.
It's reasonable to allow a project to proceed through the round if there are a small number of pages marked bad, but if the project finishes a round with any bad pages, it should probably be moved to the bad state.
The text was updated successfully, but these errors were encountered:
Resolving pages that have been marked bad works okay as long as the PM or a PF or squirrel takes care of fixing them.
Current process: If a project has 10 pages marked bad by 3 or more proofreaders, the project is marked bad and removed from the round. The PM gets an email for each page marked bad as it's marked bad.
The PM can then let it sit in the bad project state, fix the bad pages, or pull it to Unavailable.
If a project has 1-9 pages marked bad, the PM gets notifications when the pages are marked bad, but the project is not moved to the bad state, and sits in the round until someone does something about it.
As far as I can tell, PMs and PFs cannot do anything but move the project to unavailable, or back to waiting, or fix the bad pages. However, there is no block to keep a site admin from skipping a round if the project was marked bad and then moved to Unavailable.
No squirrel worth their salt would actually deliberately do something like that to a real project, but might do so accidentally. The question is, how should we be dealing with bad pages differently?
It's probably not enough to just mark the project bad. The transition from available or waiting to unavailable should be allowed if there are bad pages, but a transition from any waiting state to any available state should not be allowed if there are bad pages.
It's reasonable to allow a project to proceed through the round if there are a small number of pages marked bad, but if the project finishes a round with any bad pages, it should probably be moved to the bad state.
The text was updated successfully, but these errors were encountered: