Is the generated table too long?
Okabe-Junya opened this issue · comments
Due to the addition of features, the generated table has become long. Being able to collect many metrics is good, but if the table is too long, it becomes difficult to read.
example
| Title | URL | Author | Time to first response | Time to close | Time to answer | Time spent in waiting-for-review | Time spent in waiting-for-manager |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Monthly issue metrics report | https://github.com/Okabe-Junya/sandbox/issues/249 | github-actions[bot] | None | None | None | None | None |Originally post
When putting these tables into an issue it can be hard to read wide table with lots of entries and that is why I think this is important to be configurable. Any thoughts on that?
Originally posted by @zkoppert in #129 (comment)
I have considered several solutions to this problem, but none of them seem perfect.
- Hide some metrics by default.
- Shorten the column names (in some columns, the column name seems to be the bottleneck).
- Change the format of time display. (It might be a bit redundant when displaying time over one day in the
n days...format)
I think that solutions in this space will always be trade-offs. For example a less-wide table will not necessarily make it easier for users to read and interpret the data.
Still, worth exploring some more options.
Rendered version of your example, for comparison to the proposals below.
| Title | URL | Author | Time to first response | Time to close | Time to answer | Time spent in waiting-for-review | Time spent in waiting-for-manager |
|---|---|---|---|---|---|---|---|
| Monthly issue metrics report | Okabe-Junya/sandbox#249 | github-actions[bot] | None | None | None | None | None |
Merging Title+URL
One could possibly merge the "Title" + "URL" column into one?
Options:
- Either make the title the clickable bit
- adding an icon that the users can click
Disadvantage would be that then you don't see the repo where the issue/PR is from straight away. Matters only if the report is generated over multiple repos.
Example for (1)
| Title | Author | Time to first response | Time to close | Time to answer | Time spent in waiting-for-review | Time spent in waiting-for-manager |
|---|---|---|---|---|---|---|
| Monthly issue metrics report | github-actions[bot] | None | None | None | None | None |
Example for (2)
| Title | Author | Time to first response | Time to close | Time to answer | Time spent in waiting-for-review | Time spent in waiting-for-manager |
|---|---|---|---|---|---|---|
| 🔗 Monthly issue metrics report | github-actions[bot] | None | None | None | None | None |
Moving the "Time spent in LABEL" data to a separate table
The "Time spent in LABEL" columns can be 0 or ♾️, depending on how many labels the project wants to report on.
So this part of the table can grow really large.
Here it might be an option to split the data into two tables.
The first table with the basic information for the issue/pr, and the 2nd table with all the "Time spent in LABEL" data.
Short forms in labels?
Introducing short forms for text that frequently appears in labels could be another option e.g.
| Title | Author | TT1 first response | TT close | TT answer | TI2 waiting-for-review | TI waiting-for-manager |
|---|---|---|---|---|---|---|
| Monthly issue metrics report | github-actions[bot] | None | None | None | None | None |
Footnotes
I think your suggestion is absolutely fantastic!!
I wonder if it might be sufficient to merge the columns for title and url. Using footnotes for abbreviation seems like a great idea, but wouldn't the implementation be a bit challenging??
By also incorporating the removal of milliseconds, which was suggested in another issue, it seems we can create a table that is quite easy to read.
Just as extra context: Footnotes are implemented by default in GitHub markdown. And as the output of the issue-metrics action is a GitHub issue, we can assume those footnotes to work out of the box.
Code for the sample table shown above is this:
| Title | Author | TT[^1] first response | TT close | TT answer | TI[^2] waiting-for-review | TI waiting-for-manager |
| --- | --- | --- | --- | --- | --- | --- |
| [Monthly issue metrics report](https://github.com/Okabe-Junya/sandbox/issues/249) | github-actions[bot] | None | None | None | None | None |
[^1]: Time to
[^2]: Time spent in
Thinking about the issue here in more general terms again.
I am wondering if we should wait to see if other users confirm that this is an issue for them as well.
That might also provide is with further information about how to reliably solve for this.
So in short I am saying, let's wait a bit before we implement anything :)
Thoughts?
I wasn't familiar with the footnote specifications of Markdown, especially on GitHub. Thank you for the thorough explanation.
So in short I am saying, let's wait a bit before we implement anything :)
I agree!! This issue doesn't appear to be a high-priority bug report or a proposal that involves major changes. If we decide not to address this issue immediately, it might be worth considering adding the appropriate labels.
I didn't know about the markdown footnotes either. Very cool! Thanks for sharing @spier .
This issue is stale because it has been open 21 days with no activity. Remove stale label or comment or this will be closed in 14 days.