Constructor Blog

Get the latest news about launches, product updates, and more.

The 8 Major Differences Between Constructor and GitHub Issues/Projects

Seth Purcell
Seth Purcell
Jul 27, 2022

Most teams who use GitHub and need a place to track their work consider using GitHub’s Issues and Projects features. It’s natural to think using the same tool to organize the work and manage the code will have advantages. Yet many of these teams end up choosing not to adopt GitHub issues. Why? In our view, while GitHub has had issue-tracking features for over a decade and is continuing to improve them, we don’t think they’ve nailed it yet. If we did, we wouldn’t be building Constructor!

Fundamentally, GitHub is focused primarily (if not exclusively) on the coding workflow, especially code review and build automation. But Constructor is home base for a product development team’s entire workflow: research, design, product management, and development. Constructor and GitHub are therefore complementary: in Constructor, the whole team collaborates at the level of features (or bugs/stories/epics/etc.), while in GitHub the developers collaborate primarily at the level of code changes – which usually don’t correspond 1:1 with features. For most product development teams, both systems are essential.

Different missions usually result in different design choices. In this post we’ll go over the major differences between Constructor and GitHub, and why we’ve made the design choices we have.

1. Constructor is great for the non-devs, too

Many PMs we’ve spoken with find GitHub overwhelming because it’s designed primarily for developers. By contrast, we’ve designed Constructor from the ground up to delight everyone on the team – developers, designers, PMs, testers, everybody – without compromising the experience for any individual role. If your team is only developers this difference won’t impact you much, but if you have any PMs or designers, our research suggests they’ll probably prefer the more focused and streamlined experience of Constructor.

2. Conversations aren’t just lists of comments

Conversations are the essence of collaboration. Constructor enables real, practical collaboration via discrete conversations (threads) that can be assigned and resolved. Open threads are unmissable in a dedicated area on the right hand side of ticket pages, but when resolved, they’re hidden to minimize clutter. They’re the perfect place for logging quick requests between devs and PMs, QAs and devs, etc. – all while remaining as frictionless as a chat app like Slack.

GitHub issues, by contrast, only provide an unstructured list of non-resolvable comments that are interleaved with all other activity for the issue. They get pushed offscreen (and potentially lost track of) as unrelated new messages come in, and they can't be explicitly assigned to a team member for follow-up, so balls can get dropped all too easily.

3. “Owner + collaborators” versus “assignee(s)”

In GitHub, depending on your plan, issues can have either a single assignee or up to ten assignees in a flat, undifferentiated list. But many teams want a hybrid where there’s both a clear owner and a complete list of everyone involved – which is distinct from the list of people watching the ticket. This is the model provided by Constructor.

In Constructor, every ticket can have an explicit owner – but only one – and can also have one or more collaborators. This enables teams to run a strictly-single-owner process while still keeping track of everyone who’s involved – for example, making it clear who’s responsible for the frontend work. Constructor displays owners distinctly from collaborators so it’s easy to see what’s going on.

4. GitHub issues are bound to a single repository

For better or worse, GitHub issues are always associated with a repository, so the work is always in the context of a codebase. If a team has issues that span repositories, they either have to create a pseudo-repository that doesn’t hold any code but is just used to manage issues, or use a different tool altogether. Note that while GitHub projects can span repositories, the issues contained in projects will always be associated with exactly one repo.

Constructor, on the other hand, doesn’t tie tickets to repositories. A ticket is simply work that needs to be done and doesn’t imply or restrict which codebases are impacted (if any). On the same board, different tickets can map to work done in different codebases. In fact, even a single ticket in Constructor can be associated with pull requests to different repositories.

5. Workflow modeling and backlog support

GitHub projects offer a flexible way to collect and visualize issues across repos; a project is simply a set of statuses and a set of issues mapped to those statuses.

Constructor boards more precisely capture the reality of how teams work by modeling a workflow as a partially-ordered set of queues called stages. Each stage in Constructor is categorized as either waiting, working, or complete. A stage is still displayed as a column on a board, but Constructor’s approach enables additional capabilities. For instance, checklists can be tied to stages so that the checklist status is visible on the card when the card is in that stage. Also, cards with child tickets display progress bars showing where each child is in its respective workflow, and these progress bars are color-coded according to whether the ticket is currently in a waiting stage (gray), in a working stage (green), is blocked (red, see below), or is complete (blue). When a new board is created, it’s given one stage of each type to start with.

Every Constructor board also has a dedicated backlog that’s optimized for managing lists of ~100 tickets, and it’s hidden away by default. The backlog can be “pulled out” with a single click or keypress and stashed away just as easily. The idea is that the board should always be focused on the work being done right now, or coming up imminently, without a long backlog distracting the team.

6. Checklists and per-stage progress

Checklists are a fundamental tool for planning and tracking work, so both GitHub and Constructor support them. In GitHub, checklists are embedded in issue descriptions using extended Markdown syntax. But in Constructor, checklists are first-class citizens that can be tied to specific stages in your workflow. This lets managers see what they really want to know, namely: how close is this thing to advancing to the next stage?

For instance, let’s say your ticket has one checklist called “Design Tasks” tied to your Design stage, and another checklist called “Test Plan” tied to your QA stage. Both of these lists can be collecting tasks while the card is in the Design stage, but the progress indicated on the card will only reflect progress for the current stage’s checklist, giving you a better idea of how the work is coming along.

In both GitHub and Constructor, checklists can contain references to other tickets, but in Constructor this creates an explicit parent-child relationship between the tickets, making the child’s status visible on the parent card.

7. Explicit blockers

One of the things great managers do is obsessively find and remove obstacles blocking their teams’ progress. To keep track of tickets that are blocked, teams using GitHub usually end up creating a column called “Blocked” where they put blocked issues, or using a label to indicate an issue is blocked. But we feel that managing blockers is so important – and those solutions so inadequate – that they deserve explicit support.

In Constructor, you can create blockers on a ticket to capture a brief description of what’s blocking progress. Blockers build on discussion threads, so they also provide a place where the issue can be discussed and resolved. And blockers are displayed very prominently on the cards on the board so everyone can see there’s a problem as soon as it’s reported. You can learn more about blockers in our blog post introducing them.

8. Data model

GitHub Projects adds a model layer on top of GitHub Issues: projects contain references to issues (and pull requests), not the issues themselves. So by default, issues exist without being included in any project, making it more likely that they get lost in the shuffle, or requiring automation to keep them strictly in sync. Also, projects can track issues and PRs independently. So it’s entirely possible that a PR and the issue it pertains to appear on the same project in different positions, or are in different projects entirely. Does that really make sense? And does it even make sense for a pull request to be a top-level item in a project? Think about it. You open a pull request to achieve some goal important to your team – to implement a feature, fix a bug, etc. – often in combination with other PRs. It's that goal that should be the tracked object, the thing that explains and justifies why you made the PR. It existed before the PR was opened, and it’ll exist after the PR is merged.

In Constructor, a ticket always belongs to a board, so it's impossible for it to get lost in the ether. And a PR is always associated with a ticket (with automatic branch tracking). This association is actually bidirectional – Constructor pushes the ticket context into the PR in GitHub, and pulls the PR information from GitHub into the ticket.

In Conclusion

While it’s understandable that a team would want to track their work alongside their code and not add another tool to the mix, GitHub Issues a severe constraint in how work items can be organized and has only basic support for collaboration. Not only does Constructor directly address those weaknesses, by tightly integrating with GitHub it lets teams employ each tool where it’s strongest.

Seth Purcell
Seth Purcell is CEO and co-founder at Constructor.