Explore the July edition, featuring prompts, tips, and use cases for GitHub Copilot.
Clear communication and conversation is essential for developers. It enables teams to work efficiently and build better software.
That’s true whether you’re maintaining a large open source project, contributing to a new repository for the first time, if you and your team are working on your next release, and, really, everything in between.
We built GitHub Discussions to give you, your team, and your community a place to talk about your work, ask questions, and discuss what’s next—all right next to your code. Here are a few ways our teams use GitHub Discussions internally to build community, simplify workflows, and get key insights into our work.
Forums aren’t a new concept. If you’re anything like me, you might simultaneously be using a forum, a messaging app, a social media app, and … well you get the idea.
If that sounds stressful as a community member, imagine managing all these forums and web properties as a project maintainer. This is a big part of the job that doesn’t get as much attention, but can be time consuming to say the least. Often, you’re splitting your time between two (or more) places, and all these different platforms can leave your community siloed from your project.
Discussions provides a place to bring all those conversations together right next to your code. Whether it’s asking questions, sharing announcements, or featuring important information, it’s all in one place and easily accessible to contributors and community members alike.
Real-world examples: Next.js is a great example of a community that is really using Discussions to stay efficient and connected by talking through releases and answering questions from non-coding community members. NASA is another organization using Discussions in really cool ways, like talking through its Mission Control Technologies.
Think of it this way: Discussions are for talking and GitHub Issues are for doing. This helps minimize distractions, keep teams on track, and address topics and questions clearly in a dedicated forum. Plus, you can move seamlessly between the two as well by converting an issue to a discussion and vice versa with a simple click.
- From your discussion post, select Create issue from discussion.
- Select Submit new issue.
… and that’s it.
- From your issue, go to the bottom right corner, and select Convert to discussion.
- Pick a category to place your discussion in.
… and that’s it.
Pro tip: Discussions are easy to link out to and have ✨ infinite ✨ archived message retention. You can include links in any communication channel and easily search for past conversations or decisions.
Here’s something fun: Discussions uses the GraphQL API and webhooks to integrate with existing and new workflows—or triggers an automation with GitHub Actions. That means you can trigger responses off of Discussions to do any number of things.
At GitHub, we’ve used this to trigger chat app messages with each new discussion that’s created and answered (which is a simple, but very helpful automation for our teams). We’ve also seen open source communities use automations to trigger updates to their websites by surfacing new discussions on their community pages.
You asked, and we answered. Earlier this year, we opened up Discussions to private repositories.
Like every tool and feature we launch, we used Discussions internally at GitHub to build our internal knowledge base, talk through development plans, share updates, and more. We found that it simplified our workflows by keeping issues and pull requests centered on active work and keeping conversations, questions, and announcements separate.
Since it’s been so helpful for our internal teams, we wanted to share this with the larger GitHub community for public and private work.
Real-world examples: At GitHub, we use Discussions for teammate intros, team announcements, questions of the week, and upcoming event details.
Whether you’re releasing a new piece of software or pushing a big update (or even a new feature), Discussions can be a great place to engage with your broader community of contributors and non-coding software users to announce and answer questions about a release.
One of the most interesting use cases we’ve seen to date comes from the React Team, which used Discussions to answer questions from its community following the launch of React 18. This gave community members a place to directly contact maintainers of React 18 and also a way to get immediate help with any questions or problems.
Whether you’re a maintainer, a moderator, or part of an open source community (or a private team, for that matter), you might reach a point where there are too many discussions and not enough time to read through all of them.
When that happens, you can use the “Top Sort” feature to surface the top trending conversations in a given day, week, month, year, or from all time.
This is a quick way to see what the biggest questions, conversations, and announcements are at any given time, as well as a simple hack to save yourself time to focus on what really matters: writing great code.
Pro tip: You can also use the Unanswered menu option in Discussions to find community questions that need a—you guessed it—answer.
If you head to the Insights tab at the top of your repository, you’ll find a section called “Community” that shows you activity across your Discussions forum and project.
This dashboard gives you a quick way to monitor the following:
- The number of discussions, issues, and pull requests over time
- How many daily Discussions contributors you have
- New Discussions contributor counts by the day
- How many page views your Discussions are generating
These insights are designed to give you actionable information into your community’s health and are accessible to maintainers and administrators in your repository.
Discussions is available on GitHub Free and Teams accounts for public and private repositories—and it’s coming to GitHub Enterprise soon.
Ready to get started? Head on over to your repository, and enable Discussions in seconds. All you need is write access in a project to turn it on.