Developer Workflow

Artemis tracks upcoming work through github issues and uses the Hyperion project board to manage in progress work using the following workflow:

1. An issue is written describing a piece of work. This should be as clear as possible, ideally with measurable Acceptance Criteria. Development work should not be done without an issue describing it.

2. At the sprint meetings issues are prioritised and it is collaboratively decided what to work on for the following sprint, these will be put in the To Do column of the project board. If an issue is urgent it can be pulled into the sprint with the agreement of one other developer. Outside collaborators (e.g. those not in the MX DAQ team) are free to work on issues of their own choosing without them being prioritised this way.

3. A developer can pick any of the issues out of the To Do column to work on, when they do this they should assign the issue to themselves and move it into the In Progress column of the project board.

4. Developers should then branch of main to do the work, the branch name should be along the lines XX_description where XX is the issue number and description is a brief snake case ticket description. Each commit on the branch should reference the issue using the #XX notation.

5. When the developer is happy with the work they should make a PR merging the branch. The PR should have the following:

   • The issue number in the title
   • Fixes #XX in the description, where XX is the issue number
   • A description for the reviewer on how to test the change

   The developer should then move the issue to the Review column on the project board

6. The developer should then pick another issue from the review column to review (You can find issues that need review by using is:pr is:open review:required -assignee:XXXX in the PR search box where XXXX is your GH username

7. When reviewing you should ensure the code meets the coding standards. If you have comments for the reviewer you could add them with the following prefixes to be helpful:

   • Nit - This is arguably just taste, you don't mind if the developer doesn't follow this
   • Should - This will improve code quality but unlikely to affect functionality. If the developer doesn't want to do this they should write an explanation.
   • Must - This will negatively affect functionality if not implemented.

8. If the review passes then the reviewer should approve the change and merge it

9. If the review fails the reviewer should request any changes and move the issue back to In Progress on the project board (this issue is said to require rework)

10. A developer should ideally pick up any rework PRs before starting new work

11. When a developer is happy that a rework is complete they should press the re-request review button and move the issue back to review

Much of the movement of issues on the project board can be automated, to be done in https://github.com/DiamondLightSource/python-artemis/issues/87