Issues as Code


The Manifesto

Managing Issues is the de facto standard for working on software projects. Pull Requests and reviews are commonplace and IDEs are well integrated to work with them with minimal friction.

However, professional work done is also expected to be linked to requirements, features, tasks, issues, bugs, etc. Such concepts are typically referred to by the general term Issues popularized by Github.

The typical life cycle for an Issue is:

With frequent updates with clarifications, comments, links to documents, PR, code, images, videos, etc. Everything related to the Issue in consideration.

Depending on the project, you will be using different tools to manage Issues like Github, Jira, YouTrack, Azure Devops, Redmine, Taiga, Monday, Clickup, etc.

It is quite usual that you will need to use a Web interface to manage these issues. Without integrations with your preferred IDEs, you will add an impedance gap in your day-to-day workflow.

Problem

This context switch between the IDE (the main application in the developer workflow) and the Issue Tracker reduces productivity, generates friction, and doesn’t take advantage of the new language generation tools, like ChatGPT.

Writing an Issue is mainly text. And, why not use GitHub Copilot, for example, to help you to write the issues’ text?

It’s true you can use ChatGPT, but it’s not integrated into your project. You don’t know your source code, and it doesn’t dynamically autocomplete what you’re writing, letting you adapt the suggestion as you want to transmit it.

Solution

What if we deal with Issues as if they were Code?

What if we manage Issues as any other source code artifacts?

We do think a better way of working is possible to scale in environments where Issues are managed inside the developer IDE reducing friction to the max.

In the same way we think about Infrastructure as Code, Issues as Code provides similar advantages:

Tool

Comming soon...!