Proposal for Git Workflow

This is still a proposal under construction and should not be actively followed yet

See issue 356 for the discussions regarding this development.

I moved the information on how to add a new model to a separate page at Adding a new model

Inspiration from the GitLab Handbook

This is largely copied from the GitLab Handbook

1. Always create an issue for things you work on. If it is worth spending time on, it is worth creating an issue for it since that enables other people to learn and help. You can always edit the description or close it when the problem is something different or disappears.
2. If two issues are related, crosslink them (a link from each issue to the other one). Put the link at the top of each issue's description with a short mention of the relationship (Report, etc.). If there are more than 2 issues, use one issue as the central one and crosslink all issues to this one.
3. After a discussion about a feature update the issue body (The very first post describing the issue) with the consensus or final conclusions. This makes it much easier to see the current state of an issue for everyone involved in the implementation and prevents confusion and discussion later on.
4. Submit the smallest item of work that makes sense. When creating an issue describe the smallest fix possible, put suggestions for enhancements in separate issues and link them. If you're new to AixLib and are writing documentation or instructions, submit your first merge request for at most 50 lines.
5. Do not leave issues open for a long time, issues should be actionable and realistic. If you are assigned to an issue but don't have time to work on it, assign it to someone else. If nobody is assigned to an issue and it is not a priority, please ensure the community can help and close it. (For discussion)
6. We try not to assign issues to people but to have people pick issues in a milestone themselves.
7. Assign an issue to yourself as soon as you start to work on it, but not before that time. If you complete part of an issue and need someone else to take the next step, re-assign the issue to that person.
8. When re-assigning an issue, make sure that the issue body contains the latest information. The issue body should be the single source of truth.
9. When working on an issue, ask for feedback from your peers. For example, if you're a designer and you propose a design, ping a fellow designer to review your work. If they approve, you can move it to the next step. If they suggest changes, you get the opportunity to improve your design. This promotes collaboration and advances everyone's skills.
10. Even when something is not done, share it internally so people can comment early and prevent rework. Mark the merge request Work In Progress so it is not merged by accident.
11. When you create a merge request, mention the issue(s) that it solves in the description. If any followup actions are required on the issue after the merge request is merged, like reporting back to anyone or writing documentation, avoid auto closing it by saying Fixes #1 or Closes #1. Otherwise use auto-closing.
12. Once a merge request is created, make sure to assign it to the proper person.
13. Once a merge request has gone through review by a reviewer, they will assign it to a maintainer who will do a final review and perform the actual merge if satisfied.
14. When you are done with your merge request, remove the WIP prefix and assign the merge request to someone to review and merge it. You can still make changes based on feedback of course, but by removing the WIP prefix it clarifies that the main body of work has been completed.
15. When a merge request is done, set its milestone to the version it should be included in.
16. If you are assigned to review and merge a merge request and would like the creator to make some changes, comment on the merge request and assign it back to the creator. When they have addressed the concern, they will re-assign it to the reviewer.
17. If you are assigned to merge a merge request and there is a merge conflict, consider trying to resolve it yourself instead of asking the merge request creator to resolve the conflict. If it is easy to resolve you avoid a round trip between you and the creator, and the merge request gets merged sooner. This is a suggestion, not an obligation.
18. If you ask a question to a specific person, always start the comment by mentioning them; this will ensure they see it if their notification level is mentioned and other people will understand they don't have to respond.
19. Do not close an issue until it is fully done, which means code has been merged, all issue trackers are updated and any documentation is written and merged.
20. When closing an issue leave a comment explaining why you are closing the issue.
21. If a user suggests an enhancement, try and find an existing issue that addresses their concern, or create a new one. Ask if they'd like to elaborate on their idea in one of these issues.

Student Work

Do we need a separate guideline for students?