Notes from dev meeting December 2022

[nvaytet]

Things that went well:

• Jan-Lukas: good releases of plopp, adopted by other DRAM members
• Jan-Lukas: CI is more stable
• Jan-Lukas: good poster sessions, Scipp is becoming more known
• Simon: succeeded in delegating more, managed to not read all PRs and comment everywhere
• Neil: Plopp went well

Not so good:

• Neil/Simon: nothing has moved on ess, no new workflows, lack of input from IDSs
• Neil: Uptake on interface testing has been very slow
• Neil: still no simulated data for ESS instruments
• Simon: DMSC docs - if we don't do it ourselves, get it up and running, no one will look at it / adopt it
• Simon: Jan-Lukas needs a baby? -> Scitacean
• Simon: Stuck for too long on design discussions, try to make a decision fast, or what to do if we don't have enough info to decide.
  • either not talk about this until we have more info
  • or make a decision
  • but try not to go back and forth too much
• Jan-Lukas: despite good poster sessions, still no new users
• Jan-Lukas: we drag out stand-ups for too long, Owen used to keep us in check, Neil volunteers to be the new Owen
• Jan-Lukas: Scitacean: development was slow, context switching quite a lot (paper, code reviews, ). No feedback on anything

What are you struggling with?

• Jan-Lukas: Scitacean: No feedback on anything, no input from others -> stress, not enough time, paper got in the way. We could:
  • involve Sunyoung in the project?
  • request reviews from other Scipp members on PRs?
• Jan-Lukas: Scitacean: downloading multiple files at the same time: too many API changes in one go, broken tests for too long -> lesson learnt: make small changes instead of large ones
• Simon: context switching, not having something really concrete to work on -> organize workshop with IDSs to get more input & direction
• Neil: context switching, paper got in the way
• To help: potentially have dedicated hacking time, on e.g. wednesday afternoon?

For the future:

• Pair programming? We always said it would be good to do, but we never do it:

  • Do it more
  • Good idea to do with new starters?
  • Read up on different ways/methods of doing it?

• Simon: new commers and making them feel welcome

  • more than one of us jumped on new PRs and left comments
  • came from the feeling that we want to seem interested in the PR, but probably seemed intimidating and back-fired
  • confusing if more than one person leaves comments, decide in advance who will review
  • try not to immediately leave comments about small details (python practise), but more about design
  • in the future, should decide what level we should review this: either high-level general review, or focus on implementation

• Jan-Lukas: finishing up discussions:

  • duck arrays? (Simon: duck arrays will not work)
  • moving more things to python, etc.
  • need to finish architectural discussions before commissionning, so we have a stable base

• Neil/Simon: IDSs need data (real or simulated) to drive requirements