I’ve merged the two overlapping topics about publishing error reporting and validation reporting, as they are a major overlap. Let me chime in with my view of the matter.
When it comes to points raised by @BigRoy and @antirotor higher up here, I agree with most of the functional ones, however we’re somewhat mixing multiple topics. Artist facing report, detailed report for developer and for debugging and development and maintenance of the validators and plugins. Let’s try to break it down.
Artist facing validation report
From all the feedback it seems we need to
- provide a way to show simple structured logs, that could be generated from multiple places in the validator, same way as with all logging.
- provide at glance nicely formatted and human readable information for the artist
- Hide any information that is irrelevant to the situation (like all the successful plugins, that were previously visible
i feel that would be solved by simply adding an option to show info and warning logs in the report, next to the description. In that case it could even easily aggregate and show logs from all the instances processed by the same validator when it’s selected. Similar to this mockup.
I would be strongly against showing actual traceback anywhere in these logs though. There’s absolutely zero value in the for the artist. And it’s what the details page is for.
Success report and error report can then take the same look, just with different colour and slightly adjusted layout
Details
I think this is only missing some nicer formatting of the logs same as we had in the previous UI. Artist should never feel like they need to actually go there, while TD might spend most of their time here.
It would be valuable to add option to filter out all green plugins if the TD/dev/power user chooses to.