The GitLab issue tracker

Everything we want to do in the future is an “issue” on gitlab: https://git.xfel.eu/gitlab/SCS/documentation. Once it is done, it should be turned into an entry in the elog: https://in.xfel.eu/elog/SCS+Beamline/.

Adding a new issue

If you have something that you want to do or want somebody else to do, click on “Issues” on the GitLab main view…

… then click on “New Issue”.

Into the appearing form, enter everything you know about your issue. Below, more information can be added:

Assignee:

You may assign the issue for somebody to do it, including yourself. This may be changed later, which is useful if more than one person should have a look.

Milestone:

Here you may add when the issue should be done. In case of shutdowns, this means your issue should be worked on during said shutdown. User beamtimes are in the form of “Principal Investigator Proposal Number”, e.g. “Carley 2422”. Tasks for beamtimes typically should be done before the beamtime starts.

You may add new milestones, or just add a due date.

Labels:

You may tag your issues with as many labels as you want. You may assign the component that is worked on, where the work is. There are labels for all kinds of purposes. One noteworthy is “Group Meeting”, which you should attach to all issues you would like to discuss at the next group meeting.

Labels may be changed at any time later.

Submit:

Congratulations! you may now submit your issue.

The issue board

Click on “Board” below “Issues” to get the issue board. This is an overview which issue is in which state. You may drag and drop an issue around with your mouse. The colums are:

Backlog:

Here you find the issues nobody has taken care of yet. Pick one and work on it! You should assign yourself to the issue so that everybody knows you took responsibility.

Doing:

Here you should put the issues that you are currently working on.

Waiting:

Park issues here that you can currently not work on because you are waiting for things to happen outside your responsibilities, like other groups of XFEL, or even outside companies.

Review:

If you are not sure whether the work you did is fine, you may put it here and assign somebody (typically the issue’s author) to the review what you did. Don’t just do this for every issue, most of the time once you are done you may just close the ticket.

Documentation:

In principle, all work you do should be documented. At least leave a comment in the elog, maybe even with a link back to the issue.

Closed:

All issues here are considered done. You may nonetheless pick it up here again if you think they are not actually done.