Boosted incidents log

[viroulep]

Issue for myself to track neat features that can wait until the "core" (#1862) of incidents log is merged.

• [x] sort incidents by competition's date where they happen
• [ ] log original author of incident
• [ ] handle outdated incident
• [ ] filter incidents by competitions
• [x] for WRC members/admin, add an extra "pending digest" column + a filter
• [ ] search in public summary
• [x] display date
• [ ] for user who can_view_delegate_matters?, search also in incident private description
• [ ] for user who can_view_incident_private_sections?, search also in incident private resolution
• [ ] server side filtering and pagination (unsure if it's needed)
• [ ] make the index/show pages more mobile friendly, they are terrible right now

Kind of sorted by order of priority.

Feel free to give any idea related to making the incidents log better, especially if that would make it easier for Delegates to find precedents when they look for one!

[Laura-O]

Some comments/ideas:

• For internal purposes, it could be helpful to see the original author of an incident.
• Server-side filtering & pagination seems reasonable for me as the number of incidents might grow over time. I expect we will publish more incidents on the website than we did in the spreadsheet, especially when they are interesting for the community.
• We need to discuss what to do with "outdated" incidents, i.e. with incidents which would be ruled differently later because the regulations changed. The most awesome way to deal with these cases might be to add a marking to tags when they were created before the latest change of a regulation.

[viroulep]

For internal purposes, it could be helpful to see the original author of an incident.

(I assume we're talking about authors as in WRC members here) Right, the easiest approach I can think of now is to register some "created_by" and "resolved_by" to go with the "created_at"/"resolved_at" fields. And then display this info if present on the "show incident" view. Sounds good?

We need to discuss what to do with "outdated" incidents, i.e. with incidents which would be ruled differently later because the regulations changed. The most awesome way to deal with these cases might be to add a marking to tags when they were created before the latest change of a regulation.

Sounds pretty hard to handle all cases correctly and automatically :s Lets take the example of 3h1 which changed from banning pillowed puzzle to permitting pillowed puzzle; we would have several tags with the same name but that would actually be different. But for some other rule changes it would be fine to keep the "old" tag because it may just be a change in the wording.

Since it's possible to filter by tag, another possibility is to gather all the regulations/guidelines ids which changed in an incompatible way, filter the incidents on this list, and implement some "mark incident as outdated" feature. I have trouble finding a way to avoid a human action here :(

[viroulep]

Let me correct myself:

we would have several tags with the same name but that would actually be different.

we already have per-incident tags, so it's perfectly fine to deprecate a single tag.

So I think we can have a scenario where we give a list of tags to deprecate, and we mark them as deprecated. On the incident we can display if it's deprecated, because of which tag, and when it got deprecated.

[Laura-O]

(I assume we're talking about authors as in WRC members here) Right, the easiest approach I can think of now is to register some "created_by" and "resolved_by" to go with the "created_at"/"resolved_at" fields. And then display this info if present on the "show incident" view. Sounds good?

Yep, sounds good.

So I think we can have a scenario where we give a list of tags to deprecate, and we mark them as deprecated. On the incident we can display if it's deprecated, because of which tag, and when it got deprecated.

Yes, that sounds good as well. I think it's important to have any kind of marking to give people a hint that they should not take an incident as precedent. In an ideal scenario, the incident log will be used by delegates during competitions and this could lead to some weird situations when someone finds an old decision, adapts it and we later realize regulations have changed.

[AlbertoPdRF]

Also, I think it would make sense to order incidents by the last competition they happened in.

[Ivan-Brigidano]

Would it be possible to mark if the guideline is an ADDITION, CLARIFICATION, EXPLANATION, RECOMMENDATION, REMINDER or EXAMPLE?

[viroulep]

Unfortunately this information is not (yet) exposed by the regulations compiler, but it is present in the parsed AST (see here), so it should just be a matter of extending the json code generation here to include a new "label" entry in the returned object.