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.
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.
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.
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.
If you need any help, feel free to ask questions.
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.
Please let us know.
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.
Please let the author know 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.
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.
Please track time using the method discussed with you.
Ensure that for each block of time, we can determine:
#55 is sufficient)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.
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.
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.
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.