-
Looks like we got into the beta for GitHub Discussions. 🎉 |
Beta Was this translation helpful? Give feedback.
Replies: 22 comments
-
From what I can tell, you at least need to be logged in to view these on our repo. But maybe only those in the beta can? |
Beta Was this translation helpful? Give feedback.
-
I think those in the beta only at the moment. Not sure if this will become public later. Also not sure if there will be "private" discussions later. |
Beta Was this translation helpful? Give feedback.
-
I don't see any threading in here. Anyone know how to do it? |
Beta Was this translation helpful? Give feedback.
-
Seems like no, best you can do is quote. |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
what's going on here? Did GitHub acquire reddit? 😄 |
Beta Was this translation helpful? Give feedback.
-
I love the "Answer" button, really helps highlight "the right comment" amongst many. They can just add that to issues...no need for "discussions" if that's the only purpose. And upvotes are already a thing in Issues (via emojis) |
Beta Was this translation helpful? Give feedback.
-
Does the number of votes do anything in terms of movement up/down the page? |
Beta Was this translation helpful? Give feedback.
-
I like the "quote reply" button--- honestly all of this stuff is awesome, but why make it a new product? I think separating "bug reports" and "feature/implementation discussion" would be really helpful (especially for the Go issue tracker) But there needs to be a clear UX for that: for example: Someone might start an issue as a bug, but then it turns into a discussion. How will that work? Can you transfer an issue to a discussion and disable commenting. on the issue side? |
Beta Was this translation helpful? Give feedback.
-
One thing I just noticed is that while all discussions seem to have IDs (seemingly the same monotonically increasing ids that issues/PRs use) is that you can't currently link to them in GFM. I worry that overusing the beta could give the indication that there is work happening behind the scenes that the athens community isn't privy too (which we already sort of have with the maintainers room, but has a purpose). We should be careful when playing with this until it's more of a public beta. |
Beta Was this translation helpful? Give feedback.
-
Good point @twexler. When this becomes public maybe we should create a pinned discussion and/or issue that says nothing we did in here is binding, etc... Other ideas? |
Beta Was this translation helpful? Give feedback.
-
@marwan-at-work to answer a few of your questions here:
@twexler how can i help make sure you can use/test this feature earlier? the public beta may be a bit of a ways out and i'd like to help make sure your community doesn't assume your doing hidden work so let me know can i help here specifically. |
Beta Was this translation helpful? Give feedback.
-
Thank you @becca for the answers. I'm not sure how much research has gone into discussion but I think the Go project would be a really good case study because they use "issues" exactly for discussions amongst the community and the maintainers. And with that, there's a lot of pain points. Here's a scenario of a pain point that the Go team frequently struggles with:
However, the problem is that the discussion is happening with the entire community of hundreds and potentially thousands of people. This creates an interesting problem: not everyone can read the entire discussion but would like to voice their opinion and therefore creating a lot of slightly-duplicated opinions. The Go team actually ends up reading all of the comments and responding to people in bulk because each bulk pretty much said the same thing. Here's a perfect example of an issue (that is a lot more of a discussion than issue) and that one of the Go team members responded to people in bulk: golang/go#32437 I think Discussions has a really great opportunity for large projects such as this one. One feature I can think of is that the maintainer would have the ability to "group" similar responses together to be able to respond to them and also view them together. |
Beta Was this translation helpful? Give feedback.
-
@marwan-at-work thank you for the 🔗 - this is indeed a great example. I mentioned in https://github.com/gh-community/discussions-feedback/issues/19 having one-level deep threads, which i am hopeful might help alleviate some of these concerns BUT i realize that assumes users will use threads in a way that aligns with others' expectations. when you say |
Beta Was this translation helpful? Give feedback.
-
The way I InVision it is that there would be two ways to view a discussion: The maintainers way would be that they would group comments into categoris and be able to respond to all of them People would also be able to view that and potentially participate? But at least it would help big-project-maintainers navigate through the plethora of comments |
Beta Was this translation helpful? Give feedback.
-
@becca the reason this would super helpful is because most people won't read all the comments and therefore they would not create a thread into similar ones. But others might find a comment that is relatable and they would create a thread response with whatever additions they'd like to add. |
Beta Was this translation helpful? Give feedback.
-
@becca it took me a while to find this comment (since the issue about 1 thousand responses) but check out this comment here where the lead engineer on the Go team actually created his own program to group comments and respond to them: golang/go#32437 (comment) Which makes me think: It would be an awesome feature (on both issues and discussions) to look for responses by a particular person -- but that's a separate thing lol |
Beta Was this translation helpful? Give feedback.
-
One last comment for now: if an issue has many comments, but they were grouped, then people would be encouraged to look at that view before they add their own comment that can be potentially similar. Therefore, instead of having to go through 1 thousand comments to see whether it's worth adding your own comment, you might just go through 20 "groups of comments" which would be a lot faster. Therefore, when a maintainer adds a comment to an existing "group", they should also have a short description for what these comments have in common, maybe just a title, or maybe a tweet-level description. |
Beta Was this translation helpful? Give feedback.
-
Makes me think of Blizzard forums where replies from Blizzard staff or the developers are highlighted compared to other replies. Also brings to mind the badges we have in comments like 'Author' and 'Maintainer', to indicate the author's relationship to the repository. I could see a filter, perhaps in the sidebar, to show only comments by a particular user, or to show only comments by any maintainer of the repository. |
Beta Was this translation helpful? Give feedback.
-
Having that filter would be super cool in the FAQ as well! |
Beta Was this translation helpful? Give feedback.
-
@robjloranger Yup, afaik it's only those in the beta who can see this and any of the tangential functionality |
Beta Was this translation helpful? Give feedback.
-
@twexler this is working now! For example, this is discussion #1536. |
Beta Was this translation helpful? Give feedback.
@marwan-at-work to answer a few of your questions here:
#1