8000 Enable GitHub Discussions for ReactPHP repositories · Issue #460 · reactphp/reactphp · GitHub
[go: up one dir, main page]
Skip to content

Enable GitHub Discussions for ReactPHP repositories #460

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
SimonFrings opened this issue Aug 3, 2022 · 4 comments
Closed

Enable GitHub Discussions for ReactPHP repositories #460

SimonFrings opened this issue Aug 3, 2022 · 4 comments
Labels
question

Comments

@SimonFrings
Copy link
Member

I've been answering some tickets the last few days and came across some issues that would be better suited for GitHub Discussions. It sometimes feels wrong that someone has a question, gets this answered, and then the ticket just vanishes inside the closed issue section, never to be seen again. GitHub discussions are more long-lived than issues, thus enabling better visibility for our users.

There will still be topics that need to be addressed in issues, such as bugs, but most of them belong to a category in discussion (in my opinion). For example, tickets such as reactphp/event-loop#257 could exist under a "show and tell" section. If necessary I can come up with a short plan on which types of issues should be discussions and which not.

We also have to decide whether to open Discussions in all ReactPHP repositories or just inside this (meta) repository. If we only activate them in this repository we'd have everything (questions/feature requests) in one place, on the other hand, this can get overloaded with tickets really fast. If we'd activate them in every ReactPHP repository it could be sometimes hard to tell, if a ticket belongs in the socket or http or event-loop, etc. discussion. But there's always the choice to transfer discussions between different repositories.

Those are just a few points I want to start this discussion with. We've done the same thing in clue/framework-x a while back.

What do you think about this?
@SimonFrings
Copy link
Member Author

Had a call with @clue and @WyriHaximus about this topic.

We all agree that it is a good idea to activate discussions, the question is how to do it. It makes the most sense to bundle all tickets under one GitHub Discussion tab (inside the organization or reactphp/reactphp), maybe use tags to assign specific projects to each ticket (e.g. if it's a question regarding the socket component the tags would be "socket" and "question"). In addition, we can use issue templates in each repository to refer to our discussion section.

@clue clue added the question label Aug 14, 2022
@clue
Copy link
Member
clue commented Aug 14, 2022

I think we all agree that we want to have GitHub Discussions! 👍 We've enabled GitHub Discussions for Framework X a while ago and this has definitely helped making support requests much easier than dealing with issue tickets.

Here are some thoughts to consider:

  • Should we enable discussions for each individual component or on the project level? There are definitely discussions that deal with individual components only, but many discussions actually affect multiple components, so it looks like project-wide discussions in this meta repository make more sense.
  • If we go with project discussions, should we set up categories or labels for each component? Each discussion can be in a single category only, but may have multiple labels. As such, we may want to reuse labels also for discussions, e.g. see http and child-process .
  • If we go with project discussions, each component would not have a "Discussions" tab. We've briefly discussed if enabling discussions for each component only to create a "placeholder discussion" to direct to the project discussions instead might be a good idea. I haven't seen this used in any other projects, so I'm leaning towards not doing this here either unless we see demand in the future.
  • We should probably set up some issue templates to direct users to the discussion board instead of creating issues in the future, see e.g. Add issue templates clue/framework-x#160
  • Should we migrate existing issues to discussions? This meta repository and also our component repositories currently hold discussions in the form of issues. It might be tempting to migrate existing issues into discussions, but the migration process will lock the old ticket and duplicate the entire contents as a new discussion. As such, perhaps we should "start fresh" without migrating any existing discussions?
  • New issue tickets that are actually discus 8000 sions should probably be migrated to discussions. This will lock the issue ticket and link to the discussion instead, e.g. Please add documentation to show how to use docker to serve the project created with famework-x clue/framework-x#161
  • We probably want to mark discussions in this meta project as organization level discussions. This makes discussions obvious also on the organization level, see https://github.blog/changelog/2022-04-12-organization-discussions/. This feature is rather new and I expect this to improve in the future. For example, discussions would should up in two places like this: 🆕 Organization Discussions Private Beta community/community#13192 (original link https://github.com/community/community/discussions/13192) and https://github.com/orgs/community/discussions/13192 (original link https://github.com/orgs/community/discussions/13192). (At the time of writing this, GitHub replaces the repository discussion with a link to the organization discussion but does not detect the second link to the organization discussion.)

@WyriHaximus
Copy link
Member

Aye, let's just do this and see how it works out. I do think that a label for each component is a requirement when we start linking there, and maybe we can link directly to a specific label? Not sure if that is wise or not.

@clue
Copy link
Member
clue commented Sep 5, 2022

Join our Discussions: #463 🎉🎉🎉

@clue clue closed this as completed Sep 5, 2022
@SimonFrings SimonFrings mentioned this issue Sep 6, 2022
Merged
@SimonFrings SimonFrings mentioned this issue Oct 12, 2022
Merged
This was referenced Oct 24, 2022
Merged
Merged
Merged
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
question
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@WyriHaximus @clue @SimonFrings
0