Skip to content

2022-10-05 weekly meeting

Cycle 4 Retrospective

Attendees: Brent, Dom (partial), Ghislaine, Kriti, Mukesh, Pavish, Rajat

We wrote down notes in a FigJam document ahead of time (only accessible to core team).

What went well

  • Marketing and website related work was great
    • Various team members understood the product vision better
    • We have a better idea of how to explain Mathesar in a succinct way or to less technical users
    • Nice to have space for big-picture conversations
  • We’re done with essential features, only polish and bugs left
  • Styling looks great!
  • We’re getting better at keeping scope of tasks smaller, feels more productive
    • Fixed a bunch of bugs
  • We have authentication now!
  • We’re making progress on improving processes and feedback on the backend team

See also: shout outs section on the FigJam document.

What could have gone better

  • PR reviews remain slow for some team members’ work
  • Backend performance progress has been slow / hard to follow
  • We didn’t track the cycle very well
    • Didn’t have a specific goal for the cycle
    • Didn’t track progress
  • Plans changed mid-cycle, disrupted workflow

Ideas

  • Shorter cycles? Maybe 2 weeks each, focused on a specific goal?
  • Bring back the spreadsheet!
  • Tighten feedback loops on the backend team
    • We already discussed this yesterday at the backend meeting, just reiterating

Cycle 5 Planning

Attendees: Brent, Dom, Ghislaine, Kriti, Mukesh, Pavish, Rajat, Sean (partial)

Plan for Cycle 5: we’re going to launch our live demo and website on Nov 22, in whatever state it is. We have 6.5 weeks to get Mathesar in the best shape we can get it.

Concerns:

  • This is Thanksgiving week
    • We won’t be needing to fix anything over a holiday, this is not something any external users will be relying on.
  • Are we planning to share on Hacker News? Our performance may not be good enough for a large audience.
    • No, we’ll wait until our first release so people can download/install it
    • Live demo will be shared with a small number of people we already know
      • Can also use it for usability testing

What work is left?

  • Live demo deployment logistics
    • where?
    • testing
    • who?
    • scale?
    • dataset
  • Performance work
    • Brent: We should consider changing tactics for performance improvements.
    • Picking off low-hanging fruit seems not to be working.
    • Need separate call to decide on the approach here
    • Replacing pages depending on multiple APIs on the frontend with a single API might be useful for frontend performance
      • We shouldn’t do this until after the live demo, will need more discussion and work
  • Finish the styling in Figma
  • Implement the styling in the product
  • Usability testing & QA
  • Bugs
    • How do we track bugs in the spreadsheet?
      • Group bugs into meta issues based on some criteria and assign those to people
    • Frontend needs to help prioritize backend bugs
      • We’ll a bug prioritization session (async) and that will help with grouping
    • We need to find more bugs, we haven’t been using the product much
      • Do QA session earlier rather than later

Organizing work in a spreadsheet

How do we organize the buckets of work?

  • Features should be tracked separately
  • Styling – one row per feature
  • Live demo logistics
  • Performance
    • Backend and frontend
  • Usability testing, QA, website work as well
  • Bugs – chunk them as described above

Next steps: Kriti will organize bug triage and make a spreadsheet, will send it out.

How should we track and prioritize work?

  • Use a spreadsheet
  • Prioritize work and assign responsibility at the weekly meeting
  • Should we split the cycle into smaller 2 week chunks
    • No, if we track progress like we used to, a longer cycle is fine.
      • We lost track this time because we didn’t use a spreadsheet.
    • 2 week cycle planning might hurt our velocity because of the planning and syncing up involved.
    • Let’s try the longer cycle and circle back

Plan for performance work

Attendees: Brent, Dom, Kriti, Mukesh

Rethinking performance work:

  • Get what we have merged in - Mukesh and Dom’s PRs
    • Then call it a day
    • Dom’s metadata improvements have massive improvements based on Brent’s testing
      • Not sure if we’ll need any additional improvements for the demo
  • Notes about implementation
    • Once we figure out the prefetch approach for each type of action, we can use it for different APIs easily
    • We can try to get reflection down to constant instead of exponential time, but this is difficult
  • We can eke out more performance improvements, but is it a good use of our time?

Plan:

  • Get current PRs merged in as highest priority
    • Brent will take responsibility for Dom’s PR
    • Dom will take responsibility for Mukesh’s PR
  • Then, test current APIs on the staging server
    • Mukesh will do this
      • We’ll use the staging server since it’s most comparable to live demo.
      • Use Developer Tools “Network” tab to log times.
    • Make a spreadsheet with list of APIs over 1 second
    • Ask the frontend for input on what to prioritize
      • We’ll use a similar process as we do for bug prioritization

Backend buckets for Live Demo:

  • Bugs - 2 people can easily help with this, there are a lot
  • Deployment - 1 person needs to focus a bunch of time on this

But, there’s more performance work we could do! There are known bugs and issues!

  • If there’s an issue worth prioritizing, it’ll show up on the frontend
  • It doesn’t matter if there’s other bugs or issues you know about, it’s not worth working on them right now