Hello, Developer;

Welcome to Bonaroo. You’re here to help us help our clients build great software. This guide covers everything you need to get going, from communication to code.

Before you start

Communication

We use Slack for everything. We don’t have a fixed office. Some of us work from home, some from the office, some from wherever. Slack keeps us connected regardless.

Work hours & schedule

We don’t do fixed schedules. Most of us work weekdays roughly between 9:00 and 18:00 Amsterdam time (CET/CEST). But we care about output, not hours. If you prefer working nights or weekends, that’s fine.

Just let us know your usual availability so we can plan when to assign work and when to expect questions.

Getting started

You’re here to work on a specific project. Your first goal: get it running locally.

The project README should have everything you need. If it doesn’t, that’s a bug in the README. Let us know and we’ll fix it.

If you get stuck, ask. No question is too small.

Understanding the project

Our documentation tends to be minimal. We try to make the code and context speak for themselves. That said, we usually bring in extra hands when we’re short on time, so gaps exist.

Take some time to explore the codebase, the UI, and the README. Ask questions whenever something isn’t clear. We’d rather answer questions up front than debug misunderstandings later.

It also helps to understand the bigger picture:

The client isn’t always the end user, but their goals shape the project.

Working on issues

No issues assigned yet?

Let us know. We’ll get you set up.

You’ve been assigned an issue

Start by making sure you understand it. Issues vary wildly: some are detailed specs, some are a one-liner copied from a client email. They might describe a problem without a solution, or propose a solution without explaining the problem. Ideally they do both.

If anything is unclear, ask the issue author. If the issue doesn’t suggest a solution, comment your proposed approach before you start coding.

Document as you go

The issue is the single source of truth for that problem. If you discover relevant information elsewhere (a Slack thread, a conversation, a piece of documentation), add it to the issue. Future you (and future us) will be grateful.

For small, straightforward fixes, just solve it and move on.

Tracking time

Track your time using the method we discussed with you. For each block of time, include:

If you weren’t working on a specific issue, it’s especially important to note what you did.

We use time tracking for billing, but also to understand where time goes and how work progresses.

Repository guidelines

We follow standard commit conventions. Unless told otherwise, these guidelines apply.

The workflow

  1. Start from an issue. Every piece of code ties back to an issue.
  2. Branch from the latest main branch. Name your branch with the issue ID and a short summary: 55-create-user-index.
  3. Commit early, open a PR. After your first commit, open a Pull Request. Commit messages should finish the sentence “This commit will…”, e.g. add user index.
  4. Mark it as work in progress until your solution is complete.
  5. Request review. Once you’re done, remove the WIP status and we’ll review it.
  6. Address feedback. If changes are requested, update the PR based on the discussion.

While waiting for review, feel free to pick up another issue.

GitHub

Open a PR after your first commit. Add “WIP” to the title while it’s in progress. Remove “WIP” when it’s ready for review. Some repos use a WIP label or bot instead, we’ll let you know.

GitLab

Use “Create Merge Request” to create both a branch and MR. Prefix the title with “WIP: “ while in progress. Remove the prefix when you’re ready for review.

Questions or want to know more? We'd love to hear from you.

Get in touch