Several ways possible:

• Leave the Issues heading as today, excluding the entries from the MUST section.
• Skip the Issues header completely, sort failing tests on top of the MUST, SHOULD
  and EXTRA lists.
• Divide the Issues header in three (MUST Issues, SHOULD issues, EXTRA issues) and list entries
  under either e. g. MUST Issues or MUST

Right now, I ''think'' I prefer the second alternative... but hesitating.

Thre's a more basic question here: should f-r really fill the Issues list? Or should we limit f-r to run a number of tests, and show the results. If we sort the results (this is a no-brainer IMHO), maybe the most reasonable output would be

{{{
ISSUES

1.
2.
3.

====== MUST Items =======

Generic
[!]: Large documentation must go in a -doc subpackage.
Note: Documentation size is 10188800 bytes in 346 files.

[ ]: Package contains systemd file(s) if in need.
[ ]: Useful -debuginfo package or justification otherwise.

x: Rpmlint is run on all rpms the build produces.
Note: There are rpmlint messages (see attachment).

}}}

Some points here:
- We will force reviewer to actually list all issues, even if as simple as 'fix all ! markers in
MUST section and this or that test in SHOULD section.
- An INMHO better workflow, where reviewer first completes all the pending tests i. e.,
all complicated decisions and then summarizes the complete status as issues
- We don't trust f-r to create an issue. I like this approach.

I'm by means sure if this is the right solution. But I think it deserves a discussion

Fixes in 4d5f91a7fd2ff6eb1, c491a325b074b75 and 97e4038476986ce0.

Basically, I have
- Removed the check results for check already printed as issues.
- Sorted the results with failed first, then pending etc.
- Cleaned up the issue printout to make it look as an issue, and
to make it easier to add manual entries.

Unless there is more input in this bug, I will close it with these fixes.