Adding discussions to our workflow #7740
Replies: 2 comments
-
|
Hi, I couldn't find a simple way of sorting Discussion topics by upvotes or number of comments. However sorting through Issues is less of a hassle thanks to it's default sorting options. From what I understand, Github Discussions is still in Beta. Comments made within individual Issues could be used as the "community discussion and green light" required for a PR. If not contributors will have to navigate back and forth between Discussion topics and Issues with some things discussed in one, the other or both leading to duplicate conversations and not to mention more duplication in PR comments. Making use of Issue labels such as a "green light" label might be a solution. PR's that do not contain a link to a "green light label" Issue can be automatically closed+redirected to DRF's contributing documentation. If the problem is a high volume of incoming Issue submissions, sorting can once more be a solution. The community can be encouraged to upvote relevant Issues with a thumbs up so that only the relevant ones bubble up to your team. The bottom line is if the repo is open to receiving Issues and PR submissions from the public, it will. No matter how many polite "thanks but no thanks" one can reply back. |
Beta Was this translation helpful? Give feedback.
-
|
Hi, While I fully understand the need for coming up with higher quality issues (actionable as you say), I have the feeling that the usage of discussions instead of issues favours both a higher volume of low quality input from users and less responses for users that actually try to raise issues that include good descriptions and examples. In example I opened this discussion in which I linked a repo with a reproducible example, tests, tried to explain briefly, and added references to similar issues. I never got any reaction and have no means of knowing if it was even acknowledged, if I can improve anything on the post, etc. Don't get me wrong, I am not claiming to be in a position of expecting answers to anything raised in an open-source project; I am just saying that I feel that these discussions really feel like a constant flow of short-lived content where everyone can try their luck to get feedback (or not) - whereas I would favour stricter rules for opening issues but then actually follow-up on them (even if that means closing them). Discussions can still be used for, well, discussions. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
👋 Hi, all!
This is an introduction to us adding GitHub's "Discussions" feature into the workflow for contributions and conversations around Django REST framework.
Given the maturity of REST framework, the vast majority of "Issues" that are raised at this point are actually far more suited to being open-ended discussions, that don't require maintainer interaction in order to be closed off. In fact I think there's a pretty strong argument, that our bar for code changes is now pretty high, and that we should really strongly encourage folks away from issues and pull requests, unless there's been a discussion first, and there's a consensus that there's something worth escalating.
The huge advantage in doing so ought to be that by leaving the issue tracker for clearly considered, actionable items, we can start to get a grip again on ensuring that REST framework is well maintained rather than following in the footsteps of so many other open source projects and falling into burnout and a poorly managed issue swamp. I'm hopeful that this could be really positive for the project.
So... here's where I'm going to start on this.
We do of course also have an existing discussion forum, but there's plenty of reasons for us to prefer a workflow that's integrated into GitHub, so I'd expect us to gradually phase that out.
There will be more to say on this as we progress, but this is the starting point for now.
Beta Was this translation helpful? Give feedback.
All reactions