group incidents by year #92
Conversation
|
Might even be worthwile to use nested |
|
I like the idea of grouping by year. How about collapsing all years by default? This way, the reader sees immediately only the most relevant section: The current status. Also, the instructions on how to archive incidents would get simpler. |
|
Good idea @asteiner-swisstopo . |
|
P.S.: for the test link to reflect the most recent changes, it helps to add a dummy query param to bypass cache: https://sys-docs.dev.bgdi.ch/preview/feat_group_incidents_by_year/page/status-page.html?_=dummyvalue |
|
Cool thanks, looks as expected. Seeing it now, maybe it would be even cleaner to extract it to a separate subpage without collapsible blocks. I don't really see the advantage of having to click every section in order to be able to read it. So we would have two pages:
But no strong opinion, I let you decide. What you should fix for sure: The numbering in the README, currently each steps starts with "1.". |
|
Having subpages might be an option. How about the new commit: The incidents, grouped by year, are still on the same page. |
now grouping incidents by year and only expanding the current year by default, to improve readability. Esp. useful in years with many incidents
- Group incidents by year - Group incidents themselves, only keeping the most current / recent one expanded by default - Added a section on how to add a new incident to the status page in the README.md
Now we have three levels of containers. One that starts with 5 colons for the years, another one starting with 4 colons for the incidents and a last one, starting with 3 colons for the potentially multipe messages inside the same incident. Also, everything is collapsed by default
hansmannj
force-pushed
the
feat_group_incidents_by_year
branch
from
6307bae to
eb5cca2
Compare
asteiner-swisstopo
left a comment
asteiner-swisstopo
left a comment
There was a problem hiding this comment.
I'm not a fan because of the additional complexity but I agree that it looks tidier than before, so fine if you want to keep that.
What I would try to improve for sure is the README, see the comment below.
|
|
||
| ## How to add a new incident details section | ||
|
|
||
| 1. Edit the file [`status-page.md`](./page/status-page.md) | ||
| 1. If there already is a section of the current year, such as e.g. `::::: details 2025 {open}`, add the incident on top of that section, leaving one blank line after the `::::: details 2025` | ||
| 1. If it is the first incident of the current year, create a new section for the new year, e.g. `::::: details 2026 {open}` and already the closing `:::::`, so basically like this: | ||
|
|
||
| ```markdown | ||
| ::::: details 2026 {open} | ||
| ::::: | ||
| ``` | ||
|
|
||
| 1. Add the new incident either in the section of the new year or in the already existing section of the current year like this: | ||
|
|
||
| ```markdown | ||
| ::::: details 2026 | ||
| :::: details MONTH, DAY(, TIME) - [SHORT HEADING OF THE INCIDENT] {open} | ||
| ::: info MONTH, DAY(, Time) [LONGER HEADING OF THE INCIDENT] | ||
| [DETAILED TEXT ABOUT THE INCIDENT] | ||
| ::: | ||
| :::: | ||
| ::::: | ||
| ``` | ||
|
|
||
| The five `:` are only when you start and end a new year, otherwise, only the part that starts and ends with four `:` is relevant for you. |
There was a problem hiding this comment.
I find it difficult to understand this without seeing an example. Are these instructions even necessary now that we have an example in the code?
If you would like to keep something in the README, I would suggest making use of an example instead of spelling out every detail:
How to structure the incident history
The incident history in
status-page.mdshould be structured like in this example:::::: details 2026 :::: details Nov 12 - Incident2 {open} ::: info Nov 12, 15:30 Incident2 resolved Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. ::: ::: info Nov 12, 15:00 Incident2 detected Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. ::: :::: :::: details Oct 5 - Incident1 {open} ::: info Oct 5, 11:15 Incident1 resolved Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. ::: ::: info Oct 5, 10:00 Incident1 update Tempus leo eu aenean sed diam urna tempor. ::: ::: info Oct 5, 09:00 Incident1 detected Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. ::: :::: :::::
But having none at all would be my preference. What do you think?
Suggestion:
How about grouping incidents by year and only expanding the current year by default, to improve readability?
Esp. useful in years with many incidents
Test link