Core concepts
Here's a quick rundown of the key terms and concepts you'll encounter in Constructor and in this guide.
The top-level entity in Constructor is called an organization. It's the shared, team-wide account where you and your team members collaborate on your work. It's where you configure app-wide settings like team member roles, integrations, and billing details, among other things.
Your organization has one or more boards, and your boards contain tickets.
A ticket is a trackable representation of work to be done, whether large or small.
Each ticket has its own page in Constructor to house details like a description, attachments, discussion, and more. It's also displayed on the board in summary form as a card.
You can use tickets to represent low-level deliverables like bug fixes or chores, high-level goals like "epics" or "milestones", and anything in between. Tickets can be arranged into hierarchies with flexible parent-child relationships. But as you'll see, not everything has to be a ticket. Constructor offers other primitives like tasks and discussion threads that are lighter weight than tickets and great fits for many use cases.
If you're coming to Constructor from another tool, you might be familiar with a ticket being called an "issue", "work item", or "card".
A ticket's page provides a space and suite of primitives to help your team organize and collaborate on the work, including:
- Ownership: Designate a single ticket owner to make that person clearly accountable for the work. Optionally, add additional collaborators so they know what's on their plate too.
- Labels: Add labels to categorize or decorate your tickets and make it easier for your teammates to find and understand them.
- Checklists: Use lightweight checklists to quickly break down work into simple tasks without the overhead of extra tickets. Checklists items can also point to other tickets to create flexible hierarchies.
- Discussion: Discussion threads let you have multiple conversations related to the ticket going on in parallel. They're assignable, so it's always clear who's accountable for following up, and they're resolvable, so your tickets stay uncluttered. Blockers are discussion threads decorated with a brief summary explaining why the ticket is stuck.
- Code: A dedicated code section collates the ticket's open and merged pull requests and presents useful details like live build status, deploy preview and other CI/CD links, review requests, and more.
There are additional, optional primitives you can enable for your organization too, like ticket sizes and due dates.
Every ticket belongs to exactly one board, where it's displayed as a card.
A board is a space that houses and visualizes tickets going through the same workflow. It's also the level at which you can manage access control to tickets.
A board has a sequence of workflow stages. The stages are the steps that a ticket goes through from inception until completion. A board can have as many stages as you like or as few as two. Each stage has a type to indicate what it represents, e.g., work in progress vs. work that's completed. Stages are depicted visually on the board as columns of cards (or as separate table sections if you're viewing the board as a list).
A board also has two auxiliary locations for tickets:
- A board's backlog is a holding area for tickets that your team isn't planning to work on any time soon. It keeps the stages focused on the work in progress.
- A board's archive is the long-term holding area for tickets that have been completed and aren't likely to be referenced any time soon.
As you use Constructor, keep in mind these core aspects of our philosophy.
There is no one "best process" for how you should run your team. Different teams have different needs based on their size, the type of product they're building, their previous experience, and other factors, and their process should reflect that.
So, go ahead and experiment! You'll find that Constructor's primitives are designed to be flexible and support many ways of working. Everything is opt-in. Use the features that make sense for your team at your current stage of evolution. Ignore the ones that don't.
Because Constructor is flexible and process-neutral, it encourages you not to get lost in abstract theory or frameworks about how to manage your team. Be pragmatic and get to work. You can always evolve your process over time.
Last modified 5mo ago