This page describes the basic project management philosophy and procedure for the GstLAL search group. It includes development, operations, paper writing and anything else that is arguably a group effort associated with our team.

Overview

  • We will organize an agile-like work process. Please familiarize yourself with the above links and the documentation below.

Basic process

  • Strategy meetings (quarterly, approximately) We will have periodic strategy and planning meetings with the goal of making sure big picture priorities are recognized and that there is consensus. This will happen between 2 and 4 times per year. Each of these meetings will result in an updated ROAD MAP. The ROAD MAP will be turned into a set of epics at the end of this meeting.
  • Sprint meetings (weekly) We will have weekly sprint meetings to review previous sprint’s work, have a retrospective about what could be improved and to plan work for the coming sprint (week)
  • Standup This might not be possible to have in person, but it should happen. These are short - 5 minutes. If needed they can be virtual on e.g., mattermost, but should happen in a window. We already have a standup channel, so maybe just use that.

Concrete meeting implementation

This applies to Q1, Q2 of CY2023. Weekly meetings from 10:00-12:00 on PSU campus in 334 Whitmore or optionally zoom (but in person is strongly suggested for all healthy on-site people). Weekly standing agenda:

Time Activity
– Done before by Product owner
10:00-10:50 Sprint review (by issue)
10:50-11:10 Sprint retrospective
11:10-12:00 Sprint planning

PROPOSAL: Should our goal be to merge this meeting and the west call meeting starting in Q3 CY2023? We can try to get the broader US team on board with this way of working. We may not get buy-in from Japan, but we can figure out how to make the east call engagement best.

Mappings between gitlab features and our version of Agile

  • Epics are overarching projects relevant for the given roadmap, they are coarse-grained, but can otherwise be anything.
  • Milestones are used exclusively for sprints. This is 1:1 no exceptions
  • Issues are bite sized user stories. They are coarse-grained at the sprint level but may include multiple subtasks, which will be enumerated in the issue itself.
  • Labels should be used to facilitate all aspects of the above process from strategic planning, to day-to-day work. The should be useful for live views and retrospectives because e.g., at some point we will want to understand historical data within some category. We can also make sure that categories are getting equal attention to e.g., avoid the trap of not working on papers enough. Clear labels will help us during sprint planning.

Roles and expectations for team members

  • Scrum master These will rotate out, but they will be in charge of each sprint and are likely to be comprised of more senior people
  • Project owner. They will run the sprint weekly meetings. Probably me (chad) in the beginning, but would be happy to have this role change too.
  • Member This is literally everyone even me! (Chad)
  • Stakeholder These can me ourselves, but really I want us to note who depends on us. It seems like a small thing, but nothing these people can be motivating and clarifying, e.g., “Brian O’reilly asked us to do X during an ops call, so here is the issue for it.”

A healthy contributor should find themselves contributing to most if not all different types of epic categories over the course of a few months.

What a healthy steady-state gitlab / Agile project looks like for us.

  • Epics should be clean and high level. A good example is a paper or an analysis. We shouldn’t have more than O(1) epic per active team member. With our current team, that means O(10) open epics at any given time.
  • Milestones = sprints This is all we will use milestones for. There should always be exactly one open milestone. Both start dates and end dates must be used always without exception
  • Issues. These are coarse grained units of work that are actionable during a sprint. They should be added anytime they are thought of, but must be kept tidy since they form the backlog used for future sprint planning. Stay on top of merging / closing, etc. superseded or irrelevant issues. THESE ARE NOT BUG REPORTS. If an issue really does have a deadline it must be added not just included in the name (A good example is the daily rota). This will help with sorting and tracking progress.
    • Issues must be associated with an Epic.
    • Issues must be made in the project repo unless you know of another special (carefully thought of) arrangement, e.g., online rota in the gstlal-online project
    • Issues should have the appropriate category:: scope label
    • Issues should have a weight assigned that is an estimate of person hours
    • Issues shoudd have priority set using the “health” property
    • If there are known stakeholders, put them in the issue description
    • If there are known tasks add them using the gitlab add tasks feature
    • Issues must be closed when finished

Day in the life of someone on this team

  • You will participate in standups as coordinated by the scrum master
  • You will take guidance from the scrum master
  • You will be working toward closing one or more (but probably not more than a handful per person) issues assigned with the sprint. You will collaborate freely and not feel siloed. Help others and ask for help. You don’t have to wait until the sprint is done to close. Close as soon as things are done so we can track burndown.
  • You will be open to trying new things and building expertise while remaining diligent to make every effort to finish what you start. On the other hand, recognize your strength and be willing to put your project aside to help with a higher priority project if you are the one who can make a difference. We have shared responsibility and shared success.

FAQs and gotchas

  • NOTE: please put discussion and comments in the comments section of an issue rather than the issue description or task descriptions. It is expected that the comments section has a paper trail and that papertrail could be looked at during the sprint review.
  • NOTE: assign status closed for tasks when done, use weights for person-hour estimates; don’t use labels for status, but do use them for categories or other relevant things
  • NOTE: closing an issue does not close all sub tasks! You must close subtasks first!
  • NOTE: Avoid using tasks to hold information beyond the title because they are difficult to access and are mean to be brief, like a checklist.
  • NOTE: new issues should get weights based on authors opinion about how many hours something takes, but we can change them during sprint planning
  • NOTE: Scrum master should encourage people to put their progress in git issues and to prepare a summary for review. They should also encourage new issues throughout the week to be made available for next sprint.