Skip to content

Resolving an Issue


Open issues are reviewed weekly and the most critical ones are assigned to specific people as part of their weekly tasks. That task of resolving an issue is called a sprint. If you need more information on how those issues are being created, check this page.

A person in charge of that issue will then create a new branch, write the code necessary to solve that issue (with potentially multiple commits on that branch) and then submit a pull request to merge that branch back to the main development branch. This pull request will be reviewed by other developers and the code on that branch will potentially be edited to match everyone's satisfaction. The pull request will then be approved and the branch will be merged with the main one. For more detailed explanations on the process, check this short guide

If you haven't already make sure you read Using the SCRUM Board - it's easy!

Overview of important steps to successful coding in the BHoM

A. Preparatory work

Preparatory work is mandatory. Before doing anything review the activity in relevant repos and speak to team working in similar areas of the code. You can not start working on any part of the code before you have checked that there are no Pull Requests open for the Project or for the entire repo you want to modify. See naming convention

If the above steps are not fulfilled, coordinate with the person working on that branch. Either work on the same branch if possible, expanding the pull request to cover more issues (make sure you link all issues in the conversation of the pull request), or work locally on your machine until the other branch is merged. 1. If you choose to work on the same pull request, make sure any conversation being done is done publicly on Github to ease to process of the reviewers. 2. If Urgent and you cannot coordinate work locally, but do not branch yet

B. Solving the issue

  1. Select an Issue or raise one.

  2. Create a Branch for the specific Issue - using the correct naming convention and considering to branch or not to branch?

  3. As soon as you pushed your first commit, open a Draft Pull Request, and add the card to the Project SCRUM Board. This action will communicate to others that the repo is now locked and avoids conflicts.

  4. Push each individual Commit - keeping commits as specific and frequent as possible. Always review what files you are committing. And make sure your sprint is not drifting from the original issue.

  5. When your code is ready to be reviewed, change the stage of the pull request by marking the pull request as ready for review. Also remember to:

  6. use the fixes keyword to reference your issue
  7. assign your reviewers,
  8. include links to any test files that have been used to assist with swift review process,
  9. it is also useful to add any comments and context that can be helpful in the review process

  10. Work with your reviewer to close out

  11. On successful Merge and Rebase high five the person next to you! :tada:

Branch naming conventions

See the DevOps branching strategy.

Breaking changes

See our versioning strategy for more information on avoiding breaking changes.