sunrise choir - 17/09/2018

attendees

• mikey
• piet
• aljoscha

agenda

• checkins
• ???
• what's our team rhythms?
• what processes do we want to have?
  • in previous teams
    • what did you like?
    • what did you not like?
  • how often do we want to meet?
  • what do we want to do when we meet?
• where do our things live?
• how do we want to communicate?
• recap roles and expectations
  • how do we want to be held accountable for our work?
  • what do we want to do?
  • what don't we want to do?
• sketch out first phase of work
  • what's the surrounding work that isn't dev?
• rust best practices?
  • do we have guidelines?
• ???

previous team experiences

• piet
  • enjoyed having social elements
    • catching up in the morning, see how people are going
  • hard to deliver in a mechanical way
    • don't work well as a machine
  • tend to like a thing, work on it, then put it down and focus on something else
  • like kanban-ish board to get overview of tasks, have discussions, sort by priority, even if not organized into sprints
• aljoscha
  • first time working as a programmer
  • prefer a batch mode, get into a problem, obsess over it, figure it out, until completely done
• mikey
  • first time being a project manager
  • freedom to go deep, or pull away
  • burn out comes from not being able to pull away

rhythms

• "daily" dev diary
• weekly meeting
• monthly retrospective

processes

• kanban-ish board
• use GitHub for our own things
  • have ssbrs + sunrise-choir

accountability

• piet
  • accountability
    • at start of month, say how much gonna work
    • at end of month retro, how many hours did you work, did you do your dev diary?
  • roles
    • hesitant to write specs, but think we really need to write specs, want to get better
    • keen for rusty programming
• aljoscha
  • roles
    • not hesitant to write specs
    • like programming in rust
    • getting a coherent picture of the whole stack out of people's minds and into a document
    • thinking about how to write a really accessible implementation, what needs to be there, what doesn't need to be there
      • do we want to be a reference implementation?
      • accessibility vs performance
        • idiomatic rust doesn't care about running out of memory
        • lean towards accessibility, can always do performance later
  • accountability
    • not sure yet, we can bookmark at first retro
• mikey
  • roles
    • meta-team things
    • don't want to do project stuff
    • do want to do more governance stuff for rs and this
    • do want to be available for peering / helping etc.

stack

• piet
  • flume
• aljoscha
  • core protocol design

what is mvp?