I would like to propose enabling GitHub Discussions on the paritytech/polkadot-sdk repository.
At the moment, the issue tracker contains a mixture of genuine code issues, bugs, implementation tasks, feature requests, design ideas, broad protocol discussions, contributor questions, and general idea dumps. Many of these threads are valuable, but not all of them are immediately actionable as GitHub issues.
The scale of the issue tracker makes this more important. At the time of writing, polkadot-sdk has around 1.7k open issues, with new issues being opened regularly. When the issue tracker grows to this size, even useful idea threads can create noise and make it harder for contributors to understand what is actually actionable.
This creates a few problems:
-
It adds noise to the issue tracker.
-
It makes it harder for contributors to identify what is actively being worked on.
-
It blurs the line between actionable engineering tasks and early-stage ideas.
-
It may discourage contributors from picking up issues, because the issue list is harder to triage.
-
It makes genuine bugs and scoped implementation tasks harder to distinguish from open-ended discussion.
GitHub Discussions could provide a better place for:
-
Early-stage ideas
-
Open-ended design discussions
-
Questions from contributors
-
RFC-style proposals before they become concrete issues
-
Community feedback on potential improvements
-
Repository/process improvement suggestions
Issues could then be reserved more clearly for:
-
Bugs
-
Regressions
-
Concrete implementation tasks
-
Accepted work items
-
Clearly scoped feature requests
A few examples of currently open issues that seem closer to discussion material, at least initially:
-
#435— “NPoS: Robot-pools”
An idea-oriented proposal that feels better suited to discussion before becoming a scoped implementation task. -
#3901— “Wishlist: Users”
A useful wishlist/upvote thread, but not itself a concrete engineering issue. -
#9629— “A Polkadot SDK Tracker GitHub Project to onboard contributors…”
A repository/process improvement suggestion that could be discussed first, then converted into an issue if accepted, in the relevant repo. -
#251— “Vision: Random call generator for fuzz-testing”
A vision-oriented technical idea that could start as a discussion before being turned into implementation work.
This is not to say these issues are bad or unhelpful. Quite the opposite: they are useful examples of community input that should be preserved. The point is that the issue tracker may not be the best place for every early-stage idea, broad proposal, wishlist item, or open-ended feedback thread.
A lightweight convention could help:
-
Use Discussions for broad ideas, questions, feedback, and exploratory proposals.
-
Move discussion threads into Issues only once there is a clear, actionable task.
-
Close or convert issues that are primarily discussion-oriented.
-
Optionally create discussion categories such as:
-
Ideas
-
Questions
-
RFCs / Proposals
-
Contributor Help
-
Wishlist
-
Ecosystem Feedback
-
This would not need to be a major process change. It would simply give contributors and maintainers a clearer distinction between “something to talk about” and “something to implement”.
I think this would make the repository easier to navigate for both maintainers and external contributors, while still preserving a place for valuable community input. With the issue tracker already at around 1.7k open issues, even a small improvement in signal-to-noise ratio could be valuable.
Curious to hear whether others would find this useful, and whether the maintainers would be open to enabling Discussions on the repository.