MC Production Chief

The MC Production Chief is a shift role that takes responsibility for the preparation of new types of simulation productions, including special one-off requests. The shift runs Monday to Friday and each week counts for 5 credits in the ShiftDB.

Volunteer and self-assign

There is not (yet) any specific training for this shift, so to volunteer you just need to navigate to the My Account tab in the ShiftDB, select “MC Production Chief” from the list and click “Volunteer”.

../_images/volunteer.png

Then notify the admins of the role (currently Gloria and Adam) who will then confirm your participation. Once this is done, you should be able to see “MC Production Chief” listed under “Training” in the My Activity tab in the ShiftDB. You should then be able to self-assign.

Note

If you are not able to self-assign after your participation is confirmed, try logging out of the ShiftDB using the button on the top right and then logging back in.

../_images/logout.png

To self-assign for a specific week, navigate to the Self-Assign->MC Production Chief tab and click on the dates you want, then click the “Self Assign” button to confirm. Please remember to select a continuous slot from Monday to Friday in the same week.

../_images/assign.png

  • Unassigned dates are white

  • Dates you are currently choosing are light green

  • Dates you are assigned are dark green

  • Dates assigned to someone else are red

To confirm your assignment, you can check the calendar under “Assignments” in the My Activity tab.

Issue tracking

The starting point of the shift is the Status Issue Board in the MC Productions Setup Gitlab project. Here you can see the issues sorted by statue: “Open”, “WIP” and “Closed”.

../_images/issue_board.png

What do I look at first? Take into account the Priority and Due Date of the issues when choosing which ones to focus on.

Note

Assignees Make sure you assign yourself to issues that you are working on, and de-assign issues that are still open at the end of your shift, unless you want to carry them through to the next week (e.g. they’re almost complete).

../_images/assign1.png

Creating issues

An issue generally describes either a one-off special production request or support for a new type of production.

A new issue can be created by anyone, but we ask that the template is followed. The template is chosen from a drop-down menu above the text-box for the main body, and it populates the body with the contents of .gitlab/issue_templates/MCProdType.md.

../_images/new_issue_template.png

Then populate the sections according to the instructions in the template. Delete any sections and check-boxes that are not applicable.

Apply labels either with the /label command in the issue body (note there is already one for "MC Request :: Open") or by choosing from the drop-down menu. You should choose a “Priority :: X” label, all the applicable “Need - X” labels, a “Version :: SimX” label and one or more “SIM X” labels indicating the year/run that the issue concerns.

Finally, adjust the time estimate by modifying the /estimate 4h command pre-populated by the template, and choose a due date.

Note

If you are unsure about the meaning of a label, mouse-over it and a pop-up box should explain it in more detail.

Updating issues

Once work has started on an issue, remove the "MC Request :: Open" label and add "MC Request :: WIP". Add/remove the "Need - X" labels as appropriate and tick the boxes in the issue body when tasks are complete.

Note

Time tracking Keep track of the time spent doing tasks for each issue and add blocks of time by clicking the + icon in the Time Tracking box to the right of the issue page.

../_images/time_tracking_add.png

A summary is optional but makes the time tracking report more informative.

tt_left tt_right

Comment with links to other issues, merge requests, epics, tags/releases etc on GitLab and include descriptions of the work done in setting up the production. Also use the comments to ask for help or to remind others that they need to prepare something for us.

Closing issues

Once the production is prepared, remove the "MC Request :: WIP" label and add the appropriate "MC Request :: Ready - X" label. The issue then should only be closed once the request is submitted, or in the case of just asking for support of a new type of request, once the support is merged into LbMCSubmit and is verified as working.

Note

An issue can be closed automatically when a MR is merged by adding the phrase Closes <issue ref> in the body of the MR or a comment, where the reference to the issue takes the form lhcb-simulation/mc-productions-setup#<num>.

e.g. Closes lhcb-simulation/mc-productions-setup#19

Documentation, handover and report

Please feel free to extend, modify and update these instructions by opening a Merge Request on GitLab.

On the Monday following your shift you should have a hand-over chat with the next shifter, where you go through the status of each open issue, what needs to be done by them, what the blockers are, etc.

On the Tuesday following your shift you should give a short 5-minute report at the Simulation Meeting covering the following topics:

  • Issues opened and closed during your shift

  • Status of each open/WIP issue

  • Any updates to the documentation that you made (including requests for review)

  • Any suggestions or questions you may have

The basic structure of the report is automatically generated by a scheduled pipeline at 20:00 CERN time on Sundays. The pipelines can be viewed here and the latest report can be downloaded here.

To generate a report with an arbitrary reference date, run a new pipeline with a variable REF_DATE with value in YYYY-MM-DD format e.g. 2024-07-01.