<div class="embed-responsive embed-responsive-16by9">
  <iframe title="Conversation on prioritizing developer happiness" src="https://player.vimeo.com/video/385057083" width="640" height="480" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe>
</div>

Join us as guest speaker Dr. Arnal Dayaratna, IDC Research Director of Software Development, and Kelly Stirman, GitHub VP of Strategy, share why prioritizing developer happiness is the key to innovation.

In this webcast, you’ll learn:

- Why a better developer experience equals better software
- How to identify the right tools and support your developers need
- How insights, automation, productivity, and security tools improve the developer experience

Today’s leaders drive innovation by building better developer experiences

Resource Page for /devops/process/developing/developer-happiness-and-innovation

Developer happiness and innovation in the enterprise

<h2 style="margin-top: -5px;">What’s inside</h2>

- **Getting started with GitHub Discussions:** How to enable GitHub Discussions in your repository and popular use cases.

- **Best practices for using GitHub Discussions:** Key tips on how to use GitHub Discussions successfully as a community engagement tool.

- **GitHub Discussions vs. GitHub Issues:** When to use each: When and how to use Discussions and Issues on a project—and how to turn a Discussion into an Issue (and vice versa).

Building great software involves more than just the source code. If you have a growing community, there’s so many other things that may occupy your time. There’s roadmap planning, working with your community on potential features, succinctly sharing progress updates with collaborators, attracting and onboarding new contributors, and more. 

All of these things can be solved with a central gathering space where maintainers and contributors can all get together to capture ideas, converse, and plan for the future. 

The answer? GitHub Discussions. <a href="https://github.blog/2020-05-06-new-from-satellite-2020-github-codespaces-github-discussions-securing-code-in-private-repositories-and-more/">Launched in 2020</a>, Discussions brings community forums to GitHub making it easier for open source communities, developer teams, and companies to ask questions, share ideas, and build connections with each other — all right next to their code.

In this guide, we’ll explore GitHub Discussions, including how to use it, best practices, and how it complements other GitHub features (like Issues) to support the full developer experience. 

<h2 style="margin-top: -3px;">Getting started with GitHub Discussions: The basics</h2>

Designed for any developer community working on something together, GitHub Discussions offers a big benefit: It lives directly in your repository (aka, right where you’re already working and where your community is), reducing the context-switching that comes with managing third-party forums on other websites. 

It also gives you an asynchronous communication platform that allows for open-ended conversations, making it easier to save historical information, frequently asked questions, and feature ideas.  

<h2 style="margin-top: -3px;">How to enable GitHub Discussions in your repository</h2>

Discussions can be enabled in any public or private repository by an admin, maintainer, or anyone with write access. Here’s how: 

<ol>
<li>Open your repository settings and go to “Features”</li>
<li>Check the box next to “Discussions”</li>
<li>Create a welcome post to start your forum</li>
</ol>

It’s that simple. Don’t believe us? Here’s proof 👇. 

<div align="center"><img width="75%" alt="discussions1" src="https://resources.github.com/assets/img/whitepapers/discussions1.gif"></div>

<p class="text-center" style="padding: 10px;"><i>A GIF showing a GitHub user enabling Discussions in their repository.</i></p>
<p class="text-left"><a href="https://docs.github.com/en/discussions/quickstart#enabling-github-discussions-on-your-repository">Learn more about getting started with Discussions</a></p>

<h2 style="margin-top: -3px;">What you can do with GitHub Discussions: Examples of common use cases </h2>

Discussions gives you the ability to directly engage with your communities and collaborators, all while staying on GitHub. To help facilitate, it also provides features like labeling, marking helpful answers, upvoting, and more. 

Here are some ways open source communities and teams are using GitHub Discussions: 

<ul>
<li><b>Create community announcements:</b> Whether you’re an admin, maintainer, or contributor, you can use Discussions to make community announcements about upcoming releases, roadmap decisions, and more. Need proof? Check out how <a href="https://github.com/nodejs/node/discussions/40637">the open source community Node announced its roadmap to its community.</a></li>
<li><b>Share ideas and get community feedback:</b>  Maybe you need feedback on a problem you’re trying to solve. Or maybe you want to share ideas about new features you want to see as part of a future sprint. Discussions is designed to make community engagement simple and collaborative—and a popular use case among open source communities and teams is using it to share ideas and get feedback (take a look at <a href="https://github.com/gatsbyjs/gatsby/discussions/31599">how the open source community Gatsby did just this).</a></li>
<li><b>Discuss a new release:</b> Some open source communities use Discussions to answer questions about a new release from their wider communities—that’s something we’ve seen to great effect from the React team, which <a href="https://github.com/reactwg/react-18/discussions/4">used Discussions to field questions about its latest release</a> (and explain a little more about what that release does, too). </li>
<li><b>Spotlight important conversations by pinning them:</b> Discussions supports pinning conversations and announcements to the top of the feed which makes it easy to make sure your community or team has access to important information. <a href="https://github.com/vercel/next.js/discussions">A great example of this in action comes from the Next.JS community</a>, which pins important and helpful conversations to the top of its Discussions board.</li>
<li><b>Determine hot topics in your community:</b> You can sort all conversations in a given Discussions instance by how many upvotes they’ve received—and you can do this by day, month, year, or all time. This is a great way to keep track of what conversations are triggering the most interest in your community.</li>
<li><b>Ask questions and get answers with Q&A posts:</b> Have a question about a pull request, issue, or problem you’re confronting? Try posting a Q&A discussion to find an answer. And the best part: You can mark which responses are helpful answers so other people can quickly find out what helped you most. Want an example? Try checking out <a href="https://github.com/jspsych/jsPsych/discussions/categories/q-a">the jsPsych community Discussion board</a>, which features a number of Q&A posts (with helpful answers marked). </li>
<li><b>Coordinate engineering resources:</b> Another popular use case for Discussions among some communities is coordinating team resources and sprint planning. Not only that but you can create and assign Issues directly from your discussion, which makes it easy to plan sprints (more on this in a bit).</li>
<li><b>Hold general discussions:</b> You can use Discussions to talk shop (or life) with general posts to engage your community or team. For instance, the Next.JS community uses Discussions to <a href="https://github.com/vercel/next.js/discussions/10640">showcase what companies and websites are using its software.</a></li>
</ul>

<h2 style="margin-top: -3px;">Best practices for using and moderating GitHub Discussions</h2>

Discussions gives you a community forum right in your repository, making it easy to communicate with collaborators and foster community—all right from GitHub. 

But we all know that successful forums need moderation to make sure the conversation stays productive and helpful. Whether you’re using Discussions for a small team or as part of a large open source project, here are some best practices to keep in mind: 

<ul>
<li><b>Use labels to keep your spaces organized.</b> Discussions supports labels, which you can customize to fit your needs. These labels can be applied to any discussion and can be used to surface important information, make searching for a specific discussion easier, and help avoid duplicative content.</li>
<li><b>In Q&A discussions, mark which reply answers the question.</b> A popular use case of Discussions is Q&A posts, which can be helpful to crowdsource an answer from your team or community. But when you ask a question, be sure to mark which reply answered your question. This can help you avoid duplicative content (or necro posting). It’s also a good practice to upvote any comment or reply that’s helpful or accurate.</li>
<div align="center"><img width="75%" alt="discussions2" src="https://resources.github.com/assets/img/whitepapers/discussions2.png"></div> 
<p class="text-center" style="padding: 10px;"><i>A picture showing an answer that has been marked as helpful in a GitHub Discussions thread.</i></p>
<li><b>Use Discussions to trigger automations:</b> Discussions supports the GraphQL API—and that means you can use GitHub Actions to trigger automations off of new Discussions and comment events. Popular use cases include triggering chat app notifications when a new Discussion or comment is created, and sending automatic updates to websites with key Discussions such as announcements. </li>
<li><b>Turn collaborators into moderators and assign them triage permissions.</b> If your community is big enough, you’ll be well served by turning a number of collaborators into moderators to help you keep your Discussions instance running smoothly. You can do this by <a href="https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization">assigning triage permissions to people in your project</a>. This turns them into moderators who can mark answers, manage the forum, remote content, and more.</li>
<li><b>Use the top sort feature to find trending conversations.</b> Once a Discussions forum gets big enough (here’s looking at you Next.JS), you’ll likely find a lot of day-to-day activity and plenty of posts. If you don’t have time to go through every conversation, you can look at the top trending conversations by selecting the top sort feature and setting it to your preferred time frame (day, week, month, year, or all).</li>
</ul>
<div align="center"><img width="50%" alt="discussions3" src="https://resources.github.com/assets/img/whitepapers/discussions3.png"></div>
<p class="text-center" style="padding: 10px;"><i>A picture showing an answer that has been marked as helpful in a GitHub Discussions thread.</i></p>

<h2 style="margin-top: -3px;">GitHub Discussions vs. GitHub Issues: When to use each</h2> 

A common question among developers new to GitHub Discussions goes something like this: When should I use Discussions and when should I use Issues? 

<b>The short answer:</b> Discussions are great for questions and ideas that require team communication to make a decision, while Issues are defined pieces of work. 

<b>The slightly longer answer:</b> In any given project or sprint, you have things you need to discuss and those you need to do. Discussions are for—no surprise here—discussing things. Issues are for cataloguing the work you need to do after you’ve reached a decision about how to move forward.<br> 

<h3 style="margin-top: -1.5px;"><b>When to use GitHub Discussions</b></h3><br>
GitHub Discussions is best suited as a tool to share questions, ideas, conversations, requests for comment (RFC), resource planning, and announcements.

<h3 style="margin-top: -1.5px;"><b>When to use GitHub Issues</b></h3><br>
GitHub Issues are used to track executable pieces of work with a defined start and end point. These can include new features, fixing bugs, general updates, and tracking for epics and sprints, among other things.

<br>
Both Issues and Discussions can help you be more productive and collaborative. But when they’re used together, you can be more efficient by reserving Issues and pull requests for active work and Discussions for conversations, questions, and community engagement. 

And there’s another benefit: You can reference a discussion in an issue, which can help provide background and context for a piece of work. You can also convert an issue into a discussion if you need additional information and decisions before a task can be completed.

<h2 style="margin-top: -3px;">How to create an issue from a Discussion</h2>

Discussions offers an asynchronous communication platform that saves historical information, notes, ideas, and more. The best part: <a href="https://docs.github.com/en/issues/tracking-your-work-with-issues/creating-an-issue#creating-an-issue-from-discussion">You can create an issue directly from a discussion</a>, which means you can attach your notes and decisions that led to a piece of a work directly in an Issue. 

To do this, go to the right sidebar and click <b>Create issue from discussion</b> and then build out your issue and assign it to someone (or yourself). 

<h2 style="margin-top: -3px;">How to convert an issue into a discussion</h2>

Let’s be honest: Sometimes people use issues as a default bucket for anything that is a conversation—or doesn’t have an executable task involved. Other times, people will create an issue and then realize they need a team decision before they can start moving forward. 

In this case, you can convert an issue into a discussion by going to the bottom right corner of the issue and selecting “Convert to discussion.” 

Doing this will close and lock the issue while preserving the title, description, and author for the new discussion. 

<h2 style="margin-top: -3px;">Take this with you</h2> 

Whether you’re planning for a feature roadmap, asking questions about something you’re working on, or engaging with an open source community that’s building software you use, GitHub Discussions offers a central space for all communities—both open source and private—to connect and collaborate. 

Discussions is designed to do three things: 

<ul>
<li><b>Provide a centralized community space</b> for conversations and questions (and make the lives of maintainers easier when it comes to Issues and pull requests)</li>
<li><b>Create a place for newcomers and non-code collaborators</b> to participate in a larger community</li>
<li><b>Highlight project contributors</b> to help develop the next generation of maintainers</li>
</ul>

Try enabling it today in your public or private repositories—or engaging with any number of open source communities you’re interested in learning more about. 

<h3 style="margin-top: -3px;">Additional resources</h3> 

<ul>
<li><a href="https://github.blog/2021-11-10-7-unique-software-collaboration-features-in-github-discussions/">7 things you didn’t know you could do with GitHub Discussions</a></li>
<li><a href="https://docs.github.com/en/discussions/quickstart">Quickstart for GitHub Discussions</a></li>
<li><a href="https://github.blog/2022-01-13-how-five-open-source-communities-are-using-github-discussions/">5 open source communities using GitHub Discussions</a></li>
</ul>


GitHub Discussions brings community forums right to your public or private repositories on GitHub making it easy to communicate with your community, ask and answer questions, share updates, and more. Here’s what you need to know about GitHub Discussions, best practices, and how other open source projects are using it.

Resource Page for /devops/process/planning/discussions

What is GitHub Discussions? A complete guide


## 1. Partial org transformation

It’s possible to get DevOps up and running within your software organization and yet still not see any overall improvement to the speed of delivery. In many cases, this is due to implementing DevOps principles only in the engineering department while keeping everything else in your company’s org chart the same. Since DevOps is a more agile software delivery model, teams outside of software need to align to match, including IT, UX, product, and marketing

## 2. Incomplete testing automation

Continuous delivery also means continuous testing. Setting up test automation can be an intense, timeconsuming process, which means some teams leave certain complex tests alone to be run manually. If you go this route, you won’t be able to run the entire test suite with each commit. At best, you can run only a core set of tests upon commit, leaving the full test suite to be run periodically. This can leave bugs undiscovered until later in the workflow, making them harder to fix.

## 3. Tool integration problems

Your DevOps toolkit contains applications for things like source control, CI, deployment, testing, infrastructure provisioning, and even notifications. What are the odds they all talk to each other? Many software organizations end up managing their DevOps toolchain manually or using custom scripts to tie everything together—an approach that becomes less sustainable as more tools and cases are added. To solve this problem, GitHub recently released a new feature called [GitHub Actions](https://github.com/features/actions) that allows workflow steps to be treated as code, tying in integrations as needed.

## 4. Too much too fast

One good reason many companies move to a DevOps model is that their development teams are overworked. But an excessive workload can also cause a DevOps implementation to fail. Introducing new tools and processes to a team that’s already struggling to manage the workload is a recipe for chaos, employee burnout, and higher turnover. Re-prioritize, defer, or delegate work to contractors where possible before attempting the DevOps transition.

## 5. Unwillingness to fail

DevOps creates a more failure-tolerant environment, but that doesn’t mean failure-free. In the aftermath of a failure, many beginner DevOps organizations make the post-mortem mistake of assigning blame to a point in the workflow. Instead, treat failure as a learning opportunity. Taking an issue-solving approach is much more useful without introducing extra stress. Some companies, Netflix among them, actually cause simulated failures on purpose in order to get teams used to handling them.


## 6. Total product anarchy

The flexibility of DevOps can be both a blessing and a curse. By design, it gives DevOps teams more power and autonomy, but those teams might also end up doing things they shouldn’t. In more chaotic environments, poorly-vetted features and redesigns can be deployed, amended, or even rolled back, causing customer frustration. Before implementing DevOps, it pays to carefully design some approvals and controls into your processes.



DevOps can be a transformative practice for businesses of all sizes and types. Companies in almost every industry are using DevOps to give teams the time and freedom to tackle more challenging projects. As with all software development strategies, there are some shared pitfalls to watch out for.

/devops/process/

Developer happiness and innovation in the enterprise

What is GitHub Discussions? A complete guide

Six DevOps pitfalls for engineering leaders to avoid