I believe this is the start of scaling. Good thinking about scaling will help us in the future.

• We should decide the maximum number of checks shown to the user within the same session
• We should have a way to prioritize checks by type, eachgetting a unique order number.
  • This goes along with the priority of the check, given by the level of importance the community gives to each check
• Based on both, we calculate which checks should be shown first.
  • This implies having a way to show the total [shown + unshown] checks somewhere, and a possibility for the user to explore them.
  • Should we show new checks when the first shown are fixed? I would say yes if we have a good way to inform the user that more will come.

All of this favors mid-edit checks: highlighting the problems while they appear is a better way to see users fixing them. Exploring all checks (already shown or not yet shown) should remain possible, with a warning that higher-priority edits should be covered first.

This also opens the following questions:

• Some users like to save (you never know), and then fix the problems. Doing this, they are very likely to be reverted. Maybe we should add a step to encourage them to fix things or save the edit somewhere else.
• Should we tell users who leave unresolved major checks at the Publish stage that major these uncovered issues might lead to a revert?
• Should we consider a user experience where we can open an article and then activate Edit check for maintenance purposes, or to resume the workflow aforementioned?