This is the internal wiki describing any information useful for the *development* of DIVE. Any information useful to the users to run DIVE should not be included here, but in the documentation within the code.
[--> Teams link for flash meetings <--](https://teams.microsoft.com/l/meetup-join/19%3ameeting_OWYyMGU1M2YtNWZmNy00ODhiLTk4YjgtNTBiMzdlNTk5MmVk%40thread.v2/0?context=%7b%22Tid%22%3a%22cc95de1b-97f5-4f93-b4ba-fe68b852cf91%22%2c%22Oid%22%3a%226fca8678-5585-4cd2-9a31-03abcfbc3a9e%22%7d)
[--> View Schedule for the week <--](week_schedule)
## Project idea
The idea is to develop a graphical user interface to visualize the predictions of different diffusion models.
Find more info in the [project description](Sketch-of-DIVE-interface)
## Process description
We will be using a [Kanban-like agile process](Agile-process) to run our hackathon. The process will be mainly managed from the issue board (click on Issues > Boards on the left menu to see this board). Issues will start on the left and generally move to the right of the board as we go through the design, development, and review phases.
The lifecycle of an issue will look something like the following. Each of these steps will be described in more detail below:
1. An issue is proposed
2. The issue enters the design phase during which the issue description is expanded
3. The issue enters the development phase during which somebody writes the code for this feature. **Don't forget to add tests at this stage**. This ends with a merge request.
4. The merge request is reviewed. Once accepted, the corresponding issue is marked as done.
5.*Optionally* a screenshot of the new feature is posted on slack
### New issue proposal
Anytime you have any idea about some new feature, you can open a new issue by clicking ["Issues"](https://git.fmrib.ox.ac.uk/neichert/DIVE/-/issues) in the menu on the left and then click the "New Issue" button. The description can be as short or long as you like. Features can be as large as supporting a new MRI modality or as small as improving the documentation of some part of the code. Creating a new issue in no way implies that you want to work on it yourself, so feel free to open one for any idea that pops into your mind.
### Design phase
During the design phase we work out the details of a proposed feature. To start the design of a new feature:
- First go to the issue board by clicking [here](https://git.fmrib.ox.ac.uk/neichert/DIVE/-/boards) or going to Issues>Board in the menu on the left.
- Once there, select one of the issues from the backlog and move it to the next column (`Status:design`). Note that the total number of issues allowed to be in `Status:design` and `Status:design_done` is limited to (TBD). If this limit has been reached, please don't start designing a new feature, but instead join one of the design discussions in process or implement one of the existing features to create more space.
-**Required**: Check on slack whether anyone wants to contribute to the discussion on this feature.
- Meet with all people interested (using zoom/teams/slack) and create a detailed description of:
+ What is this feature designed to achieve?
+ In broad strokes: how will this feature be implemented?
+ What does it look like when this feature is finished? Try to be concrete in this last question.
- Update the description of the issue to reflect this discussion
- Once the feature has been clearly defined, move the issue to the `Status:design_done` column. You can now move on to some other task or start developing this feature as described below.
### Development phase
The development phase is the main process, where you do the actual coding to implement a new feature. Before starting to code, there are several steps to take to prevent multiple people implementing the same feature and hence wasted effort:
- First go to the issue board by clicking [here](https://git.fmrib.ox.ac.uk/neichert/DIVE/-/boards) or going to Issues>Board in the menu on the left.
- Once there, select one of the issues from the `Status:design_done` column and move it to the next column (`Status:development`). Note that the total number of issues allowed to be in `Status:development` and `Status:development_done` is limited to (TBD). If this limit has been reached, please don't start designing a new feature, but instead review one of the already developed features (listed in `Status:development_done`) to create more room.
-*Optional*: check on slack if anyone wants to implement this feature with you. Programming can be more fun and less error-prone if you have someone to pair program with.
- Before starting to code, make sure that your repository is up to date and that you are in a new branch specific for this feature:
```bash
$ git checkout master # make sure we are on the master branch
$ git pull origin master # updates the master branch from the main repository
$ git checkout -b <feature_name> # creates a new branch called <feature_name> where we can implement this new feature
```
- Implement the new feature (including some tests). Whenever you have made a substantial change to the code you are happy with, you should commit it (e.g., using `git commit -a`).
- Once you are done, push your code to the remote repository using `git push origin <feature_name>`. The output text will include a link that you can use to create a merge request (you can also create a merge request directly from the website).
- When you have created a merge request, move the issue on the board from `Status:development` to `Status:development_done`. Ask on slack to get someone to review your merge request.
#### Fixing minor issues/typos
During the development process (or at any time) you might spot some minor issue that you know how to fix. If it is closely related to the code you are editing anyway for a new feature, feel free to simply include the fix in the code for that feature. However, if it is located elsewhere you might want to create a merge request just for the fix:
```
$ git checkout master # go back to master from whichever branch we were working on
$ git pull origin master # get the latest version of master to see if someone else already fixed it
$ git checkout -b <bug_name> # create new branch just for this bug
# ... fix the bug
$ git commit -a # commit the changes
$ git push origin <bug_name> # push the changes to the repository
```
Once pushed, you can then create a pull request as described above. You can return whatever feature you were implementing by running `git checkout <feature_name>`.
### Review phase
## Reading resources
Along the way we collected a couple of useful links, the list which you can find [HERE](reading_resources).
