Welcome. If you're reading this, you might be hired by Charper Bonaroo. You're here to help us help our clients. To help you help us help our clients, here's a short article to describe some common instructions regarding common problems.

Before you start: Accessing our Slack

Communication within Charper Bonaroo is done within our slack. We don't have fixed locations - some work from home, some work at our office. To keep our communication independent from location, we use slack for communications.

• [ ] Ensure you have access to our Slack
• [ ] You're happy about the terms and agreements on the job

About work times, locations & schedules

We don't work on fixed schedules, but we're usually working on weekdays somewhere between 9:00 to 18:00. (Amsterdam Time, GMT +01:00 winter or +02:00 in summer). We usually don't mind if you work other hours.

We're mostly interested in getting things done. We don't mind if you're doing it at night, weekends or any other time. We do like to know what your usual schedule is, so we know when we can expect questions and when we need to ensure we've assigned some issues to you.

Getting started: Running the project

Usually you're here to work on a specific project. Ensure you've got access to the project's source, and see if you can get the project running. You should be assigned some issues soon. Before you start working on specific issues, see if you can get the project running.

The README.md on the project should always be sufficient to get started, but mistakes do slip in. If the readme wasn't sufficient to get started or you encounter any other issue, please let us know.

• [ ] Get access to the project
• [ ] Check the readme
• [ ] Ensure you're able to locally start the project
• [ ] Ensure the tests are all running & green

If you need any help, feel free to ask questions.

Understanding the project

Our projects aren't usually that well documented. We like to ensure the intent for a project is clear from code and context as far as reasonabily possible. Sometimes we just didn't have the time to properly document our project (note: we usually request help when we're low on time, not when we've time to spare).

To keep communication as low as possible, we'll assume you'll take some time to attempt to understand the application based on code, GUIs and readme, and to ask questions whenever your understanding is missing.

It might also be useful to understand who the client is. The software is here to help our client solve some problem. Often the client isn't the user of the project, but their role is still important for the project.

• [ ] Get a rough idea what the users of the project are
• [ ] Get a rough idea who the client is

You don't have any issue to work on

Please let us know.

You've been assigned an issue

Great. See if you understand the issue. Issues might be greatly detailed, or extremely short. Maybe the issue is just a dump with a quote from the client. The issue might be incomplete or unclear.

Sometimes the issue just describe a problem that needs to be fixed without a proposed solution. Sometimes the issue proposes a solution without describing the problem. Idealy the issue does both.

• [ ] Ensure you understand the problem that needs to be solved
• [ ] Ensure you see a potential solution

Please let the author now if you have any questions. If the issue is missing a suggested solution, it would be nice if you could comment your approach to solve the issue before you start working on it.

Document your progress

The issue is the central authority of information about that problem. If you found any required information about the issue outside the issue, please add the information to the issue. If you asked a question and got an answer, copy paste it into the issue.

For small issues, it's also fine to not document anything but just to create a solution.

Tracking time

Please track time using the method discussed with you.

Ensure that for each block of time, we can determine:

• [ ] What project you've worked on
• [ ] What issue you've worked on (EG #55 is sufficient)
• [ ] A small summary of the work done (EG creating a users index)

If you've not worked on a specific issue, it's especially important to mention what you've done otherwise.

We use time tracking to keep track of pay-per-hour billing, but also to keep track of progress and time spent on specific issues.

At the end of each block of time, we want to see relevant code commits, if any.

Repository Guidelines

We're using common guidelines like this one:

https://www.gnu.org/software/gnuastro/manual/html_node/Commit-guidelines.html

Unless otherwise specified.

Code starts at an issue. From an issue, a potential solution is created. This potential solution is presented in a branch, forked from the latest master branch.

After your first commit, create a Pull Request for your branch. Your branch name should include the issue ID and a short summary, eg 55-create-user-index. Your git commit should have a short message that finishes the sentence "This commit will...", eg git commit -m "add user index".

Mark your new PR as a work in progress if your solution isn't done yet. In this PR, we can keep track of progress. Keep the WIP until you're ready to propose your solution.

We'll then review the PR. If it passes review, it gets merged. If it doesn't, please fix PR based on the discussions/comments.

Feel free to work on other issues if you're waiting for a code review.

Github

Create a pull request after your first commit, and add "WIP" to the title. Remove "WIP" when you're done. Some github repos use other conventions, like a WIP label or WIP-bot. We'll let you know.

Gitlab

If you're working on gitlab, use the "Create Merge Request" feature to create both a branch and merge request. Use "WIP: " in the title to mark a PR (called a Merge Request in Gitlab) as a work in progress. When you're done, remove "WIP: " from the title.