Introducing security alerts on GitHub

Last month, we made it easier for you to keep track of the projects your code depends on with the dependency graph, currently supported in Javascript and Ruby. Today, for the over 75 percent of GitHub projects that have dependencies, we’re helping you do more than see those important projects. With your dependency graph enabled, we’ll now notify you when we detect a vulnerability in one of your dependencies and suggest known fixes from the GitHub community.

Security Alerts & Suggested Fix

How to start using security alerts

Whether your projects are private or public, security alerts get vital vulnerability information to the right people on your team.

Enable your dependency graph

Public repositories will automatically have your dependency graph and security alerts enabled. For private repositories, you’ll need to opt in to security alerts in your repository settings or by allowing access in the Dependency graph section of your repository’s Insights tab.

Set notification preferences

When your dependency graph is enabled, admins will receive security alerts by default. Admins can also add teams or individuals as recipients for security alerts in the dependency graph settings.

Respond to alerts

When we notify you about a potential vulnerability, we’ll highlight any dependencies that we recommend updating. If a known safe version exists, we’ll select one using machine learning and publicly available data, and include it in our suggestion.

Vulnerability coverage

Vulnerabilities that have CVE IDs (publicly disclosed vulnerabilities from the National Vulnerability Database) will be included in security alerts. However, not all vulnerabilities have CVE IDs—even many publicly disclosed vulnerabilities don't have them. We'll continue to get better at identifying vulnerabilities as our security data grows. For more help managing security issues, check out our security partners in the GitHub Marketplace.

This is the next step in using the world’s largest collection of open source data to help you keep code safer and do your best work. The dependency graph and security alerts currently support Javascript and Ruby—with Python support coming in 2018.

Learn more about security alerts

Life as a GitHub Intern: the Making of GitHub Field Day

Wilhelm Klopp is a student at University College London (UCL), a Campus Expert, and creator of Simple Poll—one of the most popular Slack integrations. He spent the summer of 2017 as a Developer Relations Intern on the GitHub Education team. In this post Wilhelm shares his work on GitHub Field Day over nine weeks at GitHub HQ in San Francisco.

Solving a problem for my own community

At UCL, our student community is vibrant and engaged, but after a few years, I noticed that we lacked a system for “knowledge transfer”, including a way for older leaders to train new students before they graduate. There are a few great resources out there to help solve this problem. Campus Experts, for example, is an online training community to enrich the technical community on your campus.

Personally, I was interested in developing an in-person event for student tech leaders—and GitHub Education was interested, too. For my internship, I proposed to start with a prototype event at GitHub HQ in San Francisco, and grow it to wider scale from there.

The event, later called “GitHub Field Day,” would bring together tech student leaders to learn from each others successes and mistakes, figure out what works and what doesn’t in community development, and get to know each other. Field Day would be an event where students create an agenda of their pain points and success stories. After a day of learning from each other, they could go back to their own schools and apply the lessons learned.

Interns working at GitHub HQ

Support and mentorship, the GitHub way

The first week as a GitHub intern is big—kind of like moving to new city and starting a full-time job. You move into a flat in San Francisco, meet your co-workers, and get to know the team you’ll be spending time with over the summer. The Developer Relations interns also got to join the Education team for a “mini-summit”: a twice-annual team meeting where we discuss priorities and timelines, while getting a sense of how the team works together.

Something that not very many people know about GitHub is that over 60 percent of its employees work remotely. Although all interns are based in San Francisco, we worked remotely with our GitHub team members—sometimes across multiple time zones. This can be challenging at first as you learn to use a plethora of communication tools to their fullest.

For example, if your teammate lives in Scotland and you’re in San Francisco, you might get a few Slack messages outside of working hours—or even wake up to reminders about 4 am meetings.

Intern class with hoodies
Interns have on-boarding cohort, just like GitHubbers do–and complete with swag. Here’s the whole internship class in our navy GitHub Intern hoodies.

Launching the first Field Day

Fellow interns @jasonetco and @kim-codes and I worked quickly to gear up for a successful launch, which meant we needed branding, an announcement, and a landing page for the event. Together, we managed to get it all up and running in just five days. The morning of the event, we also put together banners, name tags, and enough food to feed dozens of students.

The hard work paid off: We received hundreds of applications from students who wanted to improve their communities, and on Field Day we had a packed house. When 50 students began to walk through the door, I knew we were onto something great—everyone was excited and had a lot to talk about.

One topic was learning design for coding beginners, particularly relevant to student-run events and hackathons. Another common pain point was how to develop a group identity, and make new members of a school's tech community feel like they belong. Students also wanted to be able to connect their campus community with other schools, something they could accomplish through the relationships they built on Field Day. We even had a surprise visit from GitHub’s Senior Vice President of Technology, @jasoncwarner who did an impromptu Q&A.

I’m happy to share that Field Day lives on: all the work going into the branding, outreach, design and reflection has now shipped to 10 scheduled events around the world.

See if Field Day is visiting a city near you

Wil and Kim intern in San Francisco

Postscript shoutout: thanks @kim-codes!

Thanks to my awesome intern cohort and especially @kim-codes—my partner-intern in crime in brainstorming, ideation, and execution.

We're just wrapping up application season for our 2018 internships. If you'd like learn more or get updates on recruiting for our 2019 intern cohort, visit

Mapping crises for the American Red Cross and the UN with GitHub

How many students can help solve urgent problems within weeks of writing their first lines of code?

In Taichi Furuhashi's “Introduction to Spatial Information Systems I” at Aoyama Gakuin University in Japan, students collaborate with organizations like the American Red Cross, the World Bank, the United Nations and the Japan International Cooperation Agency.

For Furuhashi, President of CrisisMappers Japan, student engagement and active learning are his primary design principles. The relatively new program helps students work together to make new tools that solve big problems.

Furuhashi’s courses have been dedicated to alleviating disasters, and his students work on different aspects of providing accurate and up-to-the-minute data to aid in relief to NGOs and industry partners.

Design principles behind School of Global Studies and Collaboration
Design principles behind the School of Global Studies and Collaboration.

From OpenStreetMap to GitHub Gist

In July of 2017 the Asakura City region of Japan was hit with heavy rains and flooding. Whole sections of southern Japan were impassible, and residents urgently needed resources like water and food.

Organizations like the Red Cross used the Humanitarian OpenStreetMap Team’s tasking manager (called HOT for short) to post requests for analysis of affected regions.

Landslides and Flood mapping in Asakura City
Students in Taichi's class accept a request for mapping help from the Humanitarian Open Street Map tasking manager (a.k.a. HOT).

Photos of the affected regions come in via probe drone, satellite, or panoramic camera. Students draw polygons on maps that match up with these photos to show affected regions, like mudslides, downed forests, or collapsed bridges. Then they export the GeoJSON data to a GitHub Gist file (like this one) and send the analysis back to organizations the Red Cross via HOT.

Asakura-shi Sugawa area(

This map captures the heavy rain caused by Typhoon No. 3 on June 30, 2007. It’s based on images taken by helicopter by the Ministry of Land, Infrastructure and Transport. The polygons and lines indicate potentially impassable roads due to mudslide and the general reach of the flood.

The contributions that students make—their polygons and data analysis—can help authorities decide where to send resources and find flood and landslide victims. By helping local crises, the work of the class is always relevant and urgent.

GitHub 101 in Japanese

As the Director of OpenStreetMap Foundation Japan, Furuhashi involves students directly in the open source communities he’s a part of. This means mastering the GitHub flow, using GitHub Pages to make portfolio sites, and participating in open source communities.

He produced a slide deck to help onboard students to the world of GitHub and introduce them to the world of open source. The slides are, naturally, under an open license: CC BY-SA 4.0.

GitHub and Spatial Information



OpenStreetMapからGitHub Gistへ

赤十字などの組織はHumanitarian OpenStreetMap TeamのTasking Manager (略称HOT)を活用し、被災地域の分析リクエストを投稿しました。
古橋氏のクラスの学生は、Humanitarian OpenStreetMap Tasking Manager (略称HOT)からのマッピングサポートリクエストに応じました。

探査ドローン、衛星、パノラマカメラなどから被災地域の写真が届くと、学生はそれを基に、土砂崩れ、倒木、崩落した橋など、被災地域の状況を示す多角形を地図上に描きました。その後、GeoJSONデータをGitHub Gistファイル()にエクスポートし、分析結果をHOT経由で赤十字に返しました。



日本語版GitHub 101

オープンストリートマップ・ファウンデーション・ジャパンの理事として、古橋氏は自身が参加するオープンソースコミュニティに学生を直接かかわらせています。つまり、学生はGitHub Flowをマスターし、GitHub Pagesを使ってポートフォリオサイトを作成して、オープンソースコミュニティに参加しているということです。
古橋氏はスライドデッキを作成して、オープンソースの世界を紹介し、学生がGitHubの世界に入りやすくしています。これらのスライドは、当然オープンライセンス(CC BY-SA 4.0)です。


Introducing Teletype for Atom: Code collaboratively in real time

Work together in real time with Atom Teletype

Writing code with other developers can be a great way to onboard teammates, get to know how your peers think, and learn new skills. Unfortunately, writing code together can be difficult to coordinate.

Now social coding is easier than ever with Teletype for Atom—a new way to dive right into code with remote collaborators. Work together in real time with your own configurations in your own programming environment on any file you can open in Atom.

Today we’re releasing the Teletype package in beta, but there’s so much more to come. Visit to start coding together in Atom today.

Get started

Seamless collaboration with Teletype

Collaborate seamlessly

Talk through a review without latency. With Teletype, you can invite one or more of your teammates to jump right into the code. Everyone gets a cursor, and everyone can type at the same time.

Bring your own configurations

Share your code without giving up your configurations. Sharing is at the keystroke-level rather than at the pixel-level, so you can collaborate with your own key bindings, packages, and themes.

Connect peer-to-peer

All data flows over encrypted peer-to-peer connections. Our servers never see your files or edits, which maximizes your privacy and minimizes latency between you and your collaborators, regardless of your proximity to our data centers.

Build on Teletype

Best of all, Teletype is free and open source. As we continue along our roadmap and take Teletype beyond beta, we hope to see community contributors build on and extend it to other editors.

Today’s beta release is just the beginning of social coding with Atom. Our list of improvements includes support for voice communication and editor-agnostic collaboration. To learn more about Teletype and find out where it’s headed next, check out our post on the Atom Blog.

Build on your workflow with four new Marketplace apps


Today we’re welcoming four new apps to GitHub Marketplace that'll help you out with code review, deployment, and localization for your projects.

Code Review
SideCI is a code review assistant that analyzes pull requests automatically and uncovers issues like coding standard violations, potential security issues, and anti-pattern instances. Review code more efficiently, deliver products with confidence, and help your team accomplish more.

Continuous Integration
Streamline deployment to Kubernetes and manage your entire container lifecycle with Codefresh—CI/CD for containers that helps agile teams write better code faster with rapid feedback and testing cycles. Instantly spin up any code change, feature branch, and Docker image as part of a composition and share it with the entire team.

POEditor is a collaborative translation platform and localization management tool. It offers a common space for product and localization managers, developers, and translators to efficiently work together on making multilingual software.

Dependency management
MyGet provides hosted NuGet, npm, Bower, Maven, PHP Composer, and VSIX feeds for individual developers, open source projects, and corporate development teams. Create artifact feeds for developers or clients with our own artifacts and third party packages. Packages can come from your build server or an upstream package source. You can also use MyGet to build, test, and transform your source code into a compiled NuGet, npm, or PHP Composer package right from your GitHub repository.

We can’t wait to see what you do with these new apps! See how they can help your team work better or discover even more tools in GitHub Marketplace and integrate them into your workflow in minutes.

Archiving repositories

Just because a repository isn't actively developed anymore and you don't want to accept additional contributions doesn't mean you want to delete it. Now archive repositories on GitHub to make them read-only.

archived repository banner

Archiving a repository makes it read-only to everyone (including repository owners). This includes editing the repository, issues, pull requests, labels, milestones, projects, wiki, releases, commits, tags, branches, reactions and comments. No one can create new issues, pull requests, or comments on an archived repository, but you can still fork archived repositories—allowing development to continue elsewhere for archived open source projects.

To archive a repository, go to your Repository Settings Page and click Archive this repository.

archive repository button

Before archiving your repository, make sure you've changed its settings and consider closing all open issues and pull requests. You should also update your README and description to make it clear to visitors that it's no longer possible to contribute.

If you change your mind and want to unarchive your repository, click Unarchive this repository in the same place. Please note that most archived repository settings are hidden and you'll have to unarchive the repository to change them.

archived labelled repository

To learn more, check out the documentation on archiving repositories. Happy archiving!

GitHub welcomes all CI tools

GitHub and all CI tools

Continuous Integration (CI) tools help you stick to your team's quality standards by running tests every time you push a new commit and reporting the results to a pull request. Combined with continuous delivery (CD) tools, you can also test your code on multiple configurations, run additional performance tests, and automate every step until production.

There are several CI and CD tools that integrate with GitHub, some of which you can install in a few clicks from GitHub Marketplace. With so many options, you can pick the best tool for the job—even if it's not the one that comes pre-integrated with your system.

The tools that will work best for you depends on many factors, including:

  • Programming language and application architecture
  • Operating system and browsers you plan to support
  • Your team's experience and skills
  • Scaling capabilities and plans for growth
  • Geographic distribution of dependent systems and the people who use them
  • Packaging and delivery goals

Of course, it isn't possible to optimize your CI tool for all of these scenarios. The people who build them have to choose which use cases to serve best—and when to prioritize complexity over simplicity. For example, if you like to test small applications written in a particular programming language for one platform, you won't need the complexity of a tool that tests embedded software controllers on dozens of platforms with a broad mix of programming languages and frameworks.

If you need a little inspiration for which CI tool might work best, take a look at popular GitHub projects. Many show the status of their integrated CI/CD tools as badges in their We've also analyzed the use of CI tools across more than 50 million repositories in the GitHub community, and found a lot of variety. The following diagram shows the relative percentage of the top 10 CI tools used with, based on the most used commit status contexts used within our pull requests.

Our analysis also showed that many teams use more than one CI tool in their projects, allowing them to emphasize what each tool does best.

Top 10 CI systems used with based on most used commit status contexts

If you'd like to check them out, here are the top 10 tools teams use:

It's tempting to just pick the default, pre-integrated tool without taking the time to research and choose the best one for the job, but there are plenty of excellent choices built for your specific use cases. And if you change your mind later, no problem. When you choose the best tool for a specific situation, you're guaranteeing tailored performance and the freedom of interchangability when it no longer fits.

Ready to see how CI tools can fit into your workflow?

Browse GitHub Marketplace

New in the Shop: Reflective Hoodie

Temperatures are dropping, and so is this reflective new hoodie. Layer up, grab a hot beverage, and cozy up into fall while reflecting on all the commits you've made this year.

Shop now


Hoodie close up

Search repositories by license

Now you can look for repositories by their license. Search for a specific license using a query such as license:mit or license:gpl-3.0 or find repositories licensed under a particular license family—Creative Commons, for example—with a query such as license:cc. We've added a new license filter on the Advanced Search page to help you craft the right query.

License picker, advanced search page

With this update, you'll also see repository licenses in even more places around GitHub: organization and user profiles, the new Discover Repositories tab, and in search results.

License info in search results

We hope having license information more readily available will help you find projects you'd like to contribute to, as well as useful projects that fit your licensing requirements. To learn more, check out the documentation on searching repositories by license.

And the theme for Game Off 2017 is…

GitHub Game off 2017

Game Off—our fifth annual game jam celebrating open source is officially underway. The theme for this year’s jam is throwback.

Let your imagination run wild and interpret that in any way you like, but here are a few possible interpretations for inspiration:


  • a reversion to an earlier ancestral characteristic
  • a person or thing having the characteristics of a former time
  • a nostalgia for something in the past (fashion, movies, literature, games, technology)
  • something retro—a blast from the past
  • something passé—no longer fashionable or popular,
  • throwing something back—as in a ball or reply

How to participate

  1. Create a game based on the theme over the next month.
  2. Sign up for a free GitHub account if you don't already have one.
  3. Join the Game Off on If you don’t already have an account, log in with your GitHub account.
  4. Create a new repository to store the source code and any assets you’re able to share for your entry and push your changes before December 1 13:37 PDT.
  5. Submit your game through

You can participate by yourself or as a team. Multiple submissions are fine. And of course, the use of open source software is encouraged.


This year, voting will open shortly after the jam ends and is open to everyone who’s submitted a game.There’ll be plenty of time to play and vote on the entries.

As always, we'll highlight some of our favorites games on the GitHub Blog, and the world will get to enjoy (and maybe even contribute to or learn from) your creations.

It’s dangerous to go alone

If you're new to Git, GitHub, or version control…

If you're new to or game development…

The community feature is enabled for this jam—that’s a great place to ask questions specific to the Game Off, share tips, etc.

And don’t be shy—share your progress! The official Twitter hashtag for the Game Off is #GitHubGameOff.

Connect with developers around the world on the GitHub Community Forum

Introducing GitHub Community Forum

The open source community proves that when creative people get together on an open platform, great things happen: Code gets better, new technologies emerge, and the way we build software changes. Now there’s a new way to connect with developers around the world. Join the GitHub Community Forum to ask questions, swap stories, and share ideas, regardless of whether you work on public or private projects.

Explore the Community Forum

Screenshot of the GitHun Community Forum

You’re already on GitHub, contributing your skills and collaborating on code. With the Community Forum, you can also use GitHub to:

  • Learn from and support a community of 24 million developers. Tap into the collective knowledge of the world’s largest developer community—and get help from GitHub staff, too.
  • Find the answers you need when you need them. Search for information across all conversations in the Community Forum.
  • Browse tips and tricks for working better. We’ll share how-to articles on everything from cloning a repository to managing an open source community.
  • Get recognized for your contributions and expertise. Your help is important! The more you participate, the higher your rank will be.

Best of all, we’re just getting started. Head over to to write your first post, contribute to the conversation, and let us know what you think! With your feedback, we can keep growing the Community Forum in meaningful ways and release even more features in 2018.

The conversation’s already started. We hope you’ll join in!

Introducing GitHub Marketplace free trials

Try featured Marketplace apps free for 14 days

In May, we launched GitHub Marketplace—a new way to discover and purchase tools that build on your development process, from continuous integration to project management and code review. Now it’s even easier to perfect your workflow by trying featured Marketplace apps for free.

See all featured apps

Adding tools to your development process isn’t always as easy as it seems. With the launch of free trials, you can try apps in Marketplace free for 14 days to make sure you choose the right tools for your team. Get an idea of how an app can help you work better, or see how it fits into your workflow.

Marketplace is made up of dozens of integrations that work seamlessly with GitHub—and that number is growing every month. With free trials, your team can get started with new tools, refine your process, experiment with developer tools, and find ways to work better, together.

Browse Marketplace

Keep your project boards up to date, automatically

Today we're releasing the first set of project automation events. Now you can set up your project boards to make updates for you automatically, moving cards between columns when you or a teammate:

  • Add a new card to a project, moving it from from triage to a default starting column
  • Close an issue
  • Merge a pull request
  • Close a pull request with unmerged changes
  • Reopen an issue or pull request

Project board automation

Check out the documentation to learn how to automate your project boards—and stay tuned! We're working on automation for other common developer workflows, like changes in review or build status on pull requests. We'd love to hear from you about other ways we can help you to do your best work.

GitHub supports open source provisions in National Defense Authorization Act

This month, GitHub penned a letter urging the United States Senate and House of Representatives to support open source provisions in the 2018 National Defense Authorization Act (NDAA), which sets policies for the Department of Defense (DoD) budget. As the Senate and House move towards agreement on the final NDAA bill, we encourage both chambers to maintain the Senate’s open source provisions, which will ultimately benefit Americans and the global community.

Sponsored by Senators from both the Republican and Democratic parties, Mike Rounds and Elizabeth Warren, the provisions show that open source is a bipartisan issue. Section 886 would require unclassified, non-defense software that is custom developed for the DoD to be open source unless otherwise specified.

Makes sense, right? After all, DoD has a long hisory of using and creating open source software, and adopting policies to support these practices. Earlier this year, the DoD debuted, which leverages open source to engage the software community and modernize software practices at the agency. DoD is joined by a growing list of U.S. federal agencies adopting open source, including the National Security Agency and National Aeronautics and Space Administration.

We are encouraged to see governments around the world collaborating and embracing open source to promote efficiency, innovation, and security.

Our 2017 Octoverse report shows how open source is core infrastructure embraced by individual developers, startups, and the most valuable companies in the world, allowing all to innovate faster, more efficiently, and more securely.

Likewise, government engagement with open source strengthens economic competitiveness, national security, promotes new ideas and technology, and saves taxpayers' money. To learn more about how the government can benefit from open source, check out our letter!

Teaching efficient collaboration at the Hasso Plattner Institute

If you’re looking for a real-world approach to computer science education in Germany, you can find it at the Hasso Plattner Institute (HPI) in Potsdam, which offers a practical and engineering-oriented alternative to conventional computer science programs.

Students at Hasso Plattner

In one of HPI’s undergraduate software engineering courses, researchers Arian Treffer and Christoph Matthies encourage their students to make mistakes, assess where they get stuck, and reflect on their software development process. This way students learn how to deliver the best possible results when working together.

The final year undergraduate course "Software Engineering II" features a real-world software development challenge: 20-30 participants jointly develop a single system. Students form small development teams and coordinate within as well as with the other student’s teams. Tutoring, lectures and an introductory exercise are offered alongside the project. All code is published on GitHub under an open source license. Christoph says:

When you leave here, you should have an idea of how to develop software in a team. It's likely that you’ll work with others on some outdated legacy system in your later work life. As long as people have the ability to reflect on how their process, they are more likely to succeed in whatever they want to do.

Arian adds, "If you don't practice good communication and you work in a setting with multiple teams, frustration is inevitable. The first time your code is thrown away because someone else has already completed your ticket is an important learning experience."

Focusing on communication and self-organization shapes how students start coding: commit often, write clear commit messages, and learn from your mistakes. But first, students learn the basic tools and processes needed in an introductory exercise. However, managing these exercises for many students—and checking them manually—can get tedious.

Introducing Professor CI

Professor CI introduces students to technical tools using GitHub’s continuous integration services.

Participants work on their own repositories in Github and receive feedback and new challenges from the CI server when they push their code.

Arian is quick to note that using CI to help students fix their problems isn’t completely novel. The innovation, he says, is in how they use Professor CI with GitHub.

What is novel is using GitHub issues to motivate people and basically get them into the habit of tackling issues, writing tests and fixing bugs. If an Issue is done, you’re automatically sent another one that progresses the exercise—this is the new part. Prof. CI simulates a customer requesting new features, changes and bugfixes.

workflow of Professor CI
Summary of time from acceptance to completion of student tasks via Professor CI. For more details on the design and implementation, see the corresponding paper.

With Professor CI, students can work on their local machines, using their local development tools, and get the benefit of quick feedback from instructors. In turn, instructors have insight into students’ processes and code.

marking graph

Christoph adds, "Automation is great for standardized exercises, but in the actual development project that follows, we rely heavily on human interaction."

Spot the real requirement

Building software in teams requires talking to real humans, so the next step in the course is gathering clear and concrete requirements from a stakeholder. As anyone who builds software knows, that’s easier said than done.

Instead of giving students clear requirements for their final project, Treffer and Matthies assign a co-worker the role of the customer, whose primary job is to—well—be a customer.

He throws ridiculous requirements at the students, and changes his mind constantly. Then the students have to get out of the customer what to build. They don't get requirements. And the development process and all of its artifacts, they have to manage on their own.

This approach ensures that budding engineers get the close-to-real-world experience that the HPI hopes to instill. They develop real skills in listening, negotiating, and communicating that will help them code solid products and reduce wasted effort, wherever their degree takes them.

Treffer notes that students often think that development is chugging along better than it is, because they don’t yet have the experience required to identify problems as they arise. Milestones serve as natural points of reflection at which the group can work together to make processes better. They also closely monitor students, both with tutors and using GitHub tools to make sure they don't deviate too much from development best practices.

Reflect, then reflect on your reflection

Treffer and Matthies use a variety of exercises that help students find out what worked, what didn’t, and how to make next time better. The Sailboat is an exercise that students use to reflect on the development process.

Reflection exercises at HPI

In this exercise, the sun is what went right and the wind is what pushed the team in the right direction. The anchor represents what slowed the team down, and the rocks, of course, are potential future problems. Marking each feature of the boat scene allows the group to candidly diagnose how they work together.

Reflection exercises allow the students to get closer to one another and their professors to more intimately understand their students. Being able to collectively analyze and discuss what went right and what went wrong allows for some resolution to what might have been a rough sail. It also helps students learn how to collectively develop a process that will, ultimately, create better software and more efficient development time with minimal waste.

Basically, the most important aspect of our lecture is that students learn to apply what they're doing to identifying problems with their development process and learn how to improve the process. It’s about figuring out which process works best for your team and context.

For further reading: