Hi @doi-t thank you for this awesome work! I'll get to looking it over shortly.

Quick thought/question though looking at this: is Participants helpful to have here at all? 🤔

cc @mislav @vilmibm @billygriffin if you have thoughts!

is Participants helpful to have here at all? 🤔

Yeah, I have the same feeling. Personally, I have never paid attention to Participants. Maybe, it matters when many people are involved in an issue or a PR. But I guess listing lots of account names is not what gh can/want to handle in CLI. 🤔

This is how issue view looks like if we omit Participants:

Thanks @doi-t! I'm also in favor of omitting participants - it doesn't seem to add very much in the way of useful context unless we see evidence to the contrary. I'm also not sure how I feel about the truncation after three of each item. This is more of a provocative question than an actual suggestion, but what if we didn't truncate at all?

Separately, I'm curious from @mislav and @vilmibm if there are implications to this PR for scripting and machine readability?

@billygriffin Thank you for the review!

I'm also not sure how I feel about the truncation after three of each item. This is more of a provocative question than an actual suggestion, but what if we didn't truncate at all?

Actually, it is not what @ampinsk specifically guided at #663 (comment). I just applied the existing label list implementation which does the truncation for gh issue list to other metadata. I should have mentioned it. 🙇I agree with no truncation! I usually want to see all of them. Projects with column name (and Reviewers with their state) could tend to be a long line, though. 🤔

I'm 👍 removing participants; it doesn't seem very useful in this context.

Separately, I'm curious from @mislav and @vilmibm if there are implications to this PR for scripting and machine readability?

In my view, pr/issue view were not perfectly machine-readable to start with, and this PR does not have any negative implications that I can tell: it only adds a few more fields to the output.

I think that a machine-readable view command should ideally accept some kind of --format string or template so that the user can specifically request the information that they want to consume with their script. Or, if the command always outputs lots of different fields, those fields should be strictly delinated by some well-known format (e.g. JSON, YAML, TSV, etc.) and their values should never get adjusted processed for display (like we did with e.g. truncating labels with … when there were more than 3 labels).

@mislav
Through the implementation, I found that the truncation is done by the query. To address the design guide #663 (comment), I updated the query to get all metadata (first: 100) while I keep the fragments with first: 3 which truncates labels for gh issue list.
I wonder how you see the metadata output of the issue view without the truncation. I feel it is desirable because I see gh issue list as summary information and gh issue view as full information.

Here is the example of no truncation.

This PR is ready for code review too!

@vilmibm
I've removed all Participants related codes 054ec3c ✨

thank you~

Hey @doi-t, just wanted to say that we've really appreciated all of your contributions to this project and how thoughtful and open to feedback you've been. Thanks so much! 💖

@billygriffin
Thank you! It was an incredible experience working with the team. 😄 I'm still willingly open to any other contributions to this project if it's fine! 🙋‍♂️

It's absolutely fine and wonderful to hear that you'd like to continue contributing. ❤️ Feel free to ask about upcoming things you're interested in, and we'll happily @-mention you if there are things where we're looking for community contributions, especially in areas you've already contributed. Thanks again!