Is the generated table too long?

[Okabe-Junya]

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)

[Okabe-Junya]

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)

[spier]

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:

1. Either make the title the clickable bit
2. 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

1. Time to ↩

2. Time spent in ↩

[Okabe-Junya]

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.

[spier]

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

[spier]

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?

[Okabe-Junya]

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.

[zkoppert]

I didn't know about the markdown footnotes either. Very cool! Thanks for sharing @spier .

[github-actions]

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.