Guidelines for ds50daq software development

21-Jun-2013, KAB

We are now in a phase where it is important to manage and track the work that we are doing for DS-50 DAQ.

The reasons for doing this are largely self-evident, but I'll list a few anyway:
  1. The experiment has limited money to pay us, so we have a responsibility to work on their highest priority issues first and to limit the scope of our work to what they have requested.
  2. We need to focus on high priority tasks and avoid getting distracted by side issues so that we address the high priority issues in a timely way.
  3. Since the software is now being used in a production data-taking environment, we have a responsibility to provide releases that are well tested. And, one way to limit the testing burden of each new release is to only include the necessary changes.
Here are some proposed guidelines that are designed to meet these needs:
  1. We will use the Redmine Issue tracking system to track and manage our work (
    • Each of us will be responsible for updating the Issues that are assigned to us with progress reports, changes in state, etc.
    • We will ensure that all of our software changes are associated with Issues in the Redmine system
    • If we learn of an issue through email or a phone call or personal experience, we will create a Redmine Issue to track the work on the issue.
  2. We will match our code changes to the set that is needed to address the Redmine issue. And, we will match the time spent on each Redmine issue to the amount that is needed to address that specific issue.
    • When we create Redmine Issues, we will include an estimate of the time that it will take to address the issue. If it looks like the amount of time will be longer than the estimate, we will meet to discuss whether the allotted time should be increased or whether the scope of the Issue should be decreased.
    • If, during the course of investigating or fixing an issue, we discover additional software defects or design issues or other changes that need to be made, we will file those in a separate Redmine Issue, and that issue will be scheduled appropriately.
  3. We will make software changes on "feature" branches in the git code management system so that they can be included into upcoming software releases in a controlled way. Each Redmine Issue should have a corresponding "git flow" feature branch. [Is this too strict?]