Build what's next on GitHub, the place for anyone from anywhere to build anything.
Join us October 28-29 in San Francisco or online for GitHub Universe, our flagship developer event uniting people, agents, and the world's code.
Learn how you can streamline your bug reporting and issue reviewing workflows from the CEO and Co-founder of Marker.io, Gary Gapsar.
Marker.io built an integration that adds additional bug reporting functionality to GitHub. Gary Gaspar, CEO and Co-founder at Marker.io, shares how you can streamline your bug reporting and issue reviewing workflows in this post.
When your entire organization runs on GitHub, getting less technical teams like marketing, sales, and customer support to report sufficient details about bugs in issue trackers can be a real challenge. This leads to two problems.
First, bug reports are often unclear and incomplete, making it impossible for developers to understand the problem. Second, bug reports are often logged into “work-in-progress” style repositories without ever being reviewed, reproduced, or prioritized. Marker.io for GitHub paired with GitHub’s new transfer issue feature can help streamline your workflow with improved issue reporting and code reviewing.
Reporting bugs requires a number of steps and can be a time-consuming process. By using Marker.io for GitHub, you can help your development teams log actionable issues into GitHub in only three steps, without leaving your website:
During the quality assurance process for our new pricing page, imagine that you run into a problem where the dollar amount on your pricing plan is mysteriously missing. Using the Marker.io browser extension, you can take a screenshot to highlight the issue, add visual annotations, and log it in just a few clicks—without leaving the pricing page.
When a developer opens the GitHub issue tracker, any bugs reported through Marker.io are logged as new GitHub issues and always include actionable information.
As you can see, all bug reports logged via Marker.io into GitHub include the following information:
Now that we’ve collected better bug reports, we need to ensure we’re prioritizing urgent bugs first by using the new transfer issue feature.
Instead of having a single “bug tracking” repository where both developers and non-technical reporters collaborate, we recommend setting up an “inbox” issue tracker for reporters to log new bugs into, as well as a “work in progress (WIP)” issue tracker for developers to keep track of what needs to be done. For your “inbox” repositories, you could set up “website copy”, “website errors” or “product listing error” just to name a few example repositories.
These “inbox” repositories are the only places that your non-technical team members should be able to log issues into. Similarly, you want a repository dedicated to bug tracking that’s only for developers.
Once both types of issue tracking repositories are set up, your team should designate a product manager or developer to review and prioritize the most important issues. They’ll be responsible for using the new transfer issue feature in GitHub and moving issues from your “inbox” to your WIP repositories.
This is how your workflow should look in three steps:
Because your non-technical reporters and developers are not collaborating directly from the same repository, you don’t have to worry about errors being introduced, and your development team can ensure that all bugs are reviewed and fixed.
