GitHub Actions help you automate your software development workflows in the same place you store and collaborate on code. Individual actions are reusable pieces of code that let you build, test, package, or deploy projects on GitHub. But you can also use them to automate any step of your workflow.


<h3 style="padding-bottom: 15px; color: #586069;">
 How to get started in four simple steps
</h3>

<ol>
 <li>Click the “Actions” tab in your repository 
 GitHub Actions is tightly integrated with your code and with the rest of the experiences on GitHub.
 </li>
 <li>Choose the workflow that’s best for your type of project 
 GitHub Actions offers helpful workflow templates to get you started, including templates for Node.js, Rust, .NET Core, and more.
 </li>
 <li>Customize your workflow 
 You can start with the workflow templates that we provide, and then you can customize them to your project’s exact requirements.
 </li>
 <li>Once you’ve chosen your workflow, press the “start commit” button 
 Your workflow configuration lives in your repository, so the build definition is versioned alongside the finished code.
 </li>
</ol>

 GitHub Actions guide: <a href="https://help.github.com/en/actions">https://help.github.com/en/actions</a>
 
 Questions and answers on GitHub Actions: <a href="https://github.community">github.community</a>


<h3 style="padding-bottom: 15px; color: #586069;">
 Helpful terms to know
</h3>

 Action 
 A program that becomes a reusable component to be used in workflows. Actions can install software for the environment, set up authentication, or automate complex sets of tasks. You can find actions in the GitHub Marketplace, or create your own and share them with your community.
 

 Workflow 
 A configurable, automated process that you can use in your repository to build, test, package, release, or deploy your project. Workflows are made up of one or more “jobs” and can be triggered by GitHub events.


 Continuous integration (CI) 
 The software development practice of frequently committing small code changes to a shared repository. With GitHub Actions, you can create custom CI workflows that automatically build and test your code. From your repository, you can view the status of your code changes and detailed logs for each action in your workflow. CI saves developers time by providing immediate feedback on code changes to detect and resolve bugs faster.


 YAML 
 YAML stands for “Yet Another Markup Language”. It’s a human-readable markup language commonly used for configuration files, especially by CI- and <a href="https://resources.github.com/devops">DevOps</a>-focused software tools. GitHub Actions uses YAML as the basis of its configuration workflows.


 Workflow file 
 The configuration file that defines your GitHub Actions workflow. This is written in YAML and lives inside your GitHub repository in the .github/workflows directory. Each file in that directory that is named with a .yaml extension will define a unique workflow.


<h3 style="padding-bottom: 15px; color: #586069;">
 Example workflow file
</h3>

```yaml
name: CI for Node.js Project
on:
 push:
 branches: [ master ]
 pull_request:
 branches: [ master ]
jobs:
 build:
 runs-on: ubuntu-latest
 name: Build and Test
 steps:
 - uses: actions/checkout@v2
 name: Check out repository
 - uses: actions/setup-node@v1
 name: Set up Node.js
 with:
 node-version: 12
 - run: |
 npm ci
 npm run build
 npm test
 name: Build and Test
```

<h4>
 An explanation of this example workflow:
</h4>

 name 
 The name of your workflow will be displayed on your repository’s actions page.


 on 
 The events that occur on GitHub that will cause your workflow to be executed. For example, you can run your workflow on push and pull_request triggers, which will let you build your code and run your tests in a <a href="https://resources.github.com/ci-cd">Continuous Integration</a> workflow. You can add additional constraints on these triggers, like running when certain files or changed or when a certain branch is pushed to.


 jobs 
 A list of the jobs that run as part of the workflow. Each job will run independently of the others, and will run on a different virtual environment. Jobs may have a name to make them easily identifiable in the UI or in logs. Jobs contain a set of steps that will be executed, in order. This workflow has a single job, the build job.


 jobs.&lt;job-id&gt;.runs-on 
 The type of runner to use to run the given job on, either a runner provided by GitHub or a self-hosted runner that you configure. GitHub provides three main types of runners: Linux (named ubuntu-latest), Windows (named windows-latest) and macOS (named macos-latest).


 jobs.&lt;job-id&gt;.steps 
 A list of the steps that will run as part of the job. Each step will run one after another, all on the same virtual environment. By default, if any step fails then the entire job will stop. In this workflow, the build job contains three steps:
 <ol>
 <li>
 The first step uses an action named actions/checkout@v2. This is an action provided by GitHub that will check out your repository onto the runner, so that it can be built and tested.
 </li>
 <li>
 The second step uses an action named actions/setup-node@v1. This is an action provided by GitHub that will set up a particular version of Node.js on the runner. Arguments can be provided to the action in the with section; in this example, the node-version argument is set to 12, which instructs the action to put Node.js version 12 in the PATH for subsequent steps.
 </li>
 <li>
 The final step runs programs on the command-line. By default, these programs will be run with bash (on Linux and macOS) or PowerShell (on Windows). A single command may be specified, or multiple commands can be specified by starting them with a leading pipe (|) symbol.
 
 In this case, a Node.js continuous integration build will be performed by running npm ci to download and install packages from the npm registry, then running npm run build to run the build script specified by the project, and finally running npm test to run any unit tests in the project.
 </li>
 </ol>

Form_Ungated_Contact

Tell us more about your needs

Wondering how GitHub can help your business?

Everything you need to know about getting started with GitHub Actions

Resource Page for /actions/github-actions-cheat

CO-GHG-CONTACT-FY23-10Oct-01-WW-Resources-Contact-Request

GitHub Actions Cheat Sheet

By: Angela Jiang, Product Marketing Manager @Sentry

*[Sentry](https://sentry.io/welcome/) is an application monitoring platform that helps over 3.5 million developers see what actually matters, solve quicker, and learn continuously about their applications - from the frontend to the backend.*

<h2> Toolchains are complicated—developers and engineering managers are working with more tools than they probably care to count. In order to maintain efficiency in today’s world, having smart integrations in place is becoming less of a nice-to-have and more of a necessity.</h2>

At Sentry, we're focusing on [improving the developer workflow](https://blog.sentry.io/2022/05/06/workflow-2-0) and that means in part building deeper integrations with tools like Github to make it easier for developers to monitor every stage of the release cycle - giving developers a more automated deployment workflow to catch errors as quickly as code is shipped to production (with no superfluous button-clicking).

Whether you’re already using Sentry and GitHub separately, or building a deployment workflow for the first time, you can follow these steps to create an automated workflow for your team:

 - [Sign in](https://sentry.io/auth/login/) to your Sentry account
 - Connect your [GitHub repositories to Sentry](https://docs.sentry.io/product/integrations/source-code-mgmt/github/) to begin tracking commit data
 - Import your GitHub CODEOWNERS file to [automatically map issues](https://docs.sentry.io/product/issues/issue-owners/#code-owners) to teams or people in Sentry
 - Install the [Sentry Release GitHub Action](https://github.com/marketplace/actions/sentry-release) in GitHub to automatically upload sourcemaps, manage releases in Sentry and track how the release is trending

Customers like [Forethought](https://forethought.ai/), who have growing engineering teams and are shipping continuously, often operate with limited visibility into the code they ship and ownership over who should fix what once it's released. In Forethought’s case, integrating their GitHub CODEOWNERS file with Sentry allowed them to divide up and assign responsibilities to specific teams, [reducing their time to resolution by up to 94%](https://blog.sentry.io/2022/05/02/an-engineering-managers-tips-for-scaling-teams#defining-roles).

In addition to improving issue ownership, integrating GitHub with Sentry allows customers like Forethought to: 
- Automatically monitor the health of a new release and its impacts on users with Sentry Release GitHub Actions
- Create or link GitHub issues directly in Sentry
- Predict which commit caused an issue and who is likely responsible to resolve it
- Link Sentry stack traces back to the GitHub source code to see the line of code causing an error
- Resolve issues via a pull request or commit

Let’s walk through an example of how customers typically use Sentry and GitHub together and how you can see the above in action.

After a release is deployed, you head into your [Release Health](https://docs.sentry.io/platforms/android/configuration/releases/#release-health) tab within Sentry to monitor the stability, user adoption, and issues in a release so you can identify and stop the roll out of a bad release before it impacts customers. Within Release Health, you will see historical commit details and key stats like user adoption, application usage, and crash-rates. You can also view new, unhandled, regressed issues, and related performance problems in each release. 

![Sentry screen shot](//images.ctfassets.net/wfutmusr1t3h/6B01Y7E1ynj59MPXSjHGTq/09072f16a26588f0225dcdd20f8bc188/Sentry4.png)

With the [Sentry Release GitHub Action](https://github.com/marketplace/actions/sentry-release) installed, every new release (major or minor) will be automatically recorded and [suspect commits](https://docs.sentry.io/product/cli/releases/#sentry-cli-sourcemaps) automatically configured. Sentry will also upload the original, untransformed source code (aka [sourcemaps](https://docs.sentry.io/product/cli/releases/#sentry-cli-sourcemaps)) which un-minifies any Javascript code that is present. You can see when a release is not trending well by looking at key metrics such as the user adoption and crash-free session rate. 

![Sentry image 1](//images.ctfassets.net/wfutmusr1t3h/6BynkLIwSS0z6L3GHO3CS0/e245a166103fb599c05df87db8f0d190/Sentry1.png)

With the GitHub CODEOWNERS file synced to Sentry’s Code Owners rules, Sentry will not only capture the issue impacting users, but will also surface the specific commit related to the issue and automatically suggest the right team member to triage the issue. This way, you no longer need to scramble to figure out who is responsible for what when critical outages occur. 

![Sentry image 2](//images.ctfassets.net/wfutmusr1t3h/6sNxO3E0qkiqcN57Ghjbi5/9d2ecb917889876a783e95016d087573/Sentry2.png)

From here, you can create a GitHub issue directly from Sentry and tag the suggested assignee to an issue.

![Sentry screen shot ](//images.ctfassets.net/wfutmusr1t3h/1mWMC7oNxUPQkSoRnS7VLq/9c68b750edb78a21e5e0e96c65b39c7a/sentry5.png)

By clicking into the Sentry error report, the developer assigned to the issue can see the stack trace and easily navigate to the relevant GitHub file that is deep linked in the stack trace to investigate the issue further. 

![Sentry screen shot](//images.ctfassets.net/wfutmusr1t3h/2GOLy1bEkMUT2PiL2D1idr/7a2b4e84ee30c62e00f7a5e3c3fc61d8/sentry6.png)

Lastly, the developer who owns the issue can quickly identify what the problem is, fix it, and open a pull request with the Sentry Issue ID included in the comments. (Sentry automatically annotates the matching issue with a reference to the commit or pull request, and, later, when that commit or pull request is part of a release, mark the issue as resolved). 

![Sentry image 3](//images.ctfassets.net/wfutmusr1t3h/5upZY2BsVxt515vikOkZqM/357c4b2f2e7154abdb90e81c3c043b84/Sentry3.png)

By integrating GitHub with Sentry, you will be able to unlock the full potential of both tools to simplify your team’s workflow, increase speed to resolution, and learn from trends to optimize code health over time. 

As we continue to strive to improve how developers ship and improve software, [we'd love to hear from you](https://github.com/getsentry/sentry/issues/34327)-what part of the workflow works well, what is completely terrible, and what can we do better?

New to Sentry and want to try it out for free? [Sign up](https://sentry.io/signup/) or try out the latest version of the Action [here](https://github.com/marketplace/actions/sentry-release).

Whether you’re already using Sentry and GitHub separately, or building a deployment workflow for the first time, you can follow these steps to create an automated workflow for your team

Resource Page for /actions/integrating-with-sentry

Integrating GitHub with Sentry to Increase Speed to Resolution 

<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>

A GIF showing a GitHub user enabling Discussions in their repository.
<a href="https://docs.github.com/en/discussions/quickstart#enabling-github-discussions-on-your-repository">Learn more about getting started with Discussions</a>

<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>Create community announcements: 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>Share ideas and get community feedback: 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>Discuss a new release: 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>Spotlight important conversations by pinning them: 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>Determine hot topics in your community: 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>Ask questions and get answers with Q&A posts: 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>Coordinate engineering resources: 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>Hold general discussions: 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>Use labels to keep your spaces organized. 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>In Q&A discussions, mark which reply answers the question. 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> 
A picture showing an answer that has been marked as helpful in a GitHub Discussions thread.
<li>Use Discussions to trigger automations: 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>Turn collaborators into moderators and assign them triage permissions. 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>Use the top sort feature to find trending conversations. 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>
A picture showing an answer that has been marked as helpful in a GitHub Discussions thread.

<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? 

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

The slightly longer answer: 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. 

<h3 style="margin-top: -1.5px;">When to use GitHub Discussions</h3> 
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;">When to use GitHub Issues</h3> 
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.

 
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 Create issue from discussion 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>Provide a centralized community space for conversations and questions (and make the lives of maintainers easier when it comes to Issues and pull requests)</li>
<li>Create a place for newcomers and non-code collaborators to participate in a larger community</li>
<li>Highlight project contributors 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

Secure financial software development is important and failure to properly safeguard data can have profound impact on a company.

Resource Page for /financial-services/secure-software-development

Software development in the financial sector—Security is important

The on-demand video is here. If you’re interested in experimenting with the projects presented, we made all the source code of the demos publicly available—and you can find out more in the [GitHub Winterfest 2023 repository](https://github.com/github-winterfest-2023).
 

<div class="embed-responsive embed-responsive-16by9">
 <iframe src="https://www.youtube.com/embed/-ZElrarlCyw" width="640" height="375" frameborder="0" allowfullscreen></iframe>
</div>

### What was in store: 

- __From code to cookies: A sweet and simple guide to GitHub Projects__ 
In this session, we’ll teach you how to use GitHub Projects to make your holiday baking easier and more fun. You’ll learn how to create a project board, add issues and pull requests, and move them across different stages of your baking pipeline.

- __Fast-track your season’s greetings using GitHub and AI__ 
Are you finding it stressful getting all those season’s greetings in the (virtual) mail? Using automation and AI on GitHub, you can accelerate the process and make sure that all your loved ones receive a beautiful AI-crafted message just in time.

- __AI-powered winter whimsy: Create a poetry generator with GitHub Copilot and Codespaces__ 
Explore the synergy between human imagination and AI as we build a winter-themed poetry generator using GitHub Copilot and Codespaces. Whether you’re a developer or a poetry enthusiast (or both!), we hope you’ll join us for this literary adventure. 

We look forward to welcoming you again to our next event!

form-webcast-signup

Sign Up to Join

That's a wrap! Thank you for joining us at GitHub Winterfest 2023!

Winterfest Banner

Resource Page for /github-winterfest-2023-webinar

CO-GHDO-WBNR-FY24-11Nov-06-GitHub Winterfest 2023

GitHub Winterfest 2023


Successful software developers build together the same way at work—an approach known as “innersource.” These innersource best practices will help your team create a developer culture that is effective and collaborative.

## Be transparent

Transparency is the baseline for any innersource culture, just as it is for the wider open source community.

- Share projects across your organization as broadly as possible. Exceptions can be made for projects that require a higher level of security on a case-by-case basis.
- Ensure that your team has the tools and processes to communicate openly and build consistently—and that those tools and processes are being used. If they’re not, find out why and make adjustments until you establish a solid routine.
- Confirm that your engineering initiatives are well-resourced and supported by leadership.
- Give developers enough autonomy to contribute to projects outside their immediate teams.

## Distribute workloads

To effectively adopt innersource practices, contributors need to be able to work easily across teams and organizational silos.

- Make approvals and reviews more effective by distributing control across a smaller group of participants. A small, cross-functional team of decision-makers can also help teams stick to quality standards and get support from leadership.
- Spread heavy workloads across geographically distributed developers or even with non-developer team members.
- Keep in mind that non-developers are a valuable asset to your innersource community.
  - **Project managers** can quickly assess the state of the project, and changes made to project timelines can be tied directly to the code in question.
  - **Technical writers** should be encouraged to work alongside project engineers, precisely documenting code features where they originate.
  - **Security engineers** can review code for compliance and security-related weaknesses, preventing issues earlier in the workflow.

## Encourage communication and ongoing review

Openly sharing work and feedback brings more ideas into your innersource community—and more code.

- Make ample use of your version control system’s commenting, tagging, and review features.
- Use forks and branches so developers can try different changes without affecting original projects. These tools also make it easy to start with existing solutions, instead of writing new code each time.
- Encourage developers to share their latest work early on and often by tagging others in their code commits.
- If someone finds a bug, they should create an issue describing the problem. Tag that same contributor when you update the code so they know the bug has been fixed.
- Make each step in the software development lifecycle (such as testing and deployment) visible to everyone.

## Don’t forget the documentation

As innersource projects become more complex, in-code documentation keeps work moving and consistent.

- Document by default, not as an afterthought. Effective documentation makes your decision process clear to outside contributors and avoids wasted resources and duplication.
- Add README and CONTRIBUTING guides to all repositories to help everyone understand basic usage and project best practices.
- Use documentation to help onboard and acclimate new contributors and other participants into your process.
- Update in-code documentation regularly to keep user guides and manuals in sync with the latest version of the code.


Collaboration, transparency, and code reuse aren’t just found in open source communities.

Software Development

GitHub Actions Cheat Sheet

Integrating GitHub with Sentry to Increase Speed to Resolution

What is GitHub Discussions? A complete guide

Software development in the financial sector—Security is important

GitHub Winterfest 2023

Best practices for a collaborative software development culture

How to improve code with code reviews

Regression Testing: Definition, Types, and Tools

What is a programming language?

Understanding the SDLC: Software Development Lifecycle Explained

What is software architecture?

What is software development?

What is software testing?

What is technical debt?

What is software engineering?