Skip to content

2022-11-28 planning meeting

Attendees: Entire core team + Anish

Cycle 5 retrospective


  • FigJam file with everyone’s notes (link is not public)
  • 126 items closed!
  • Many shoutouts!
  • Styling work bleeding into feature work will hopefully smooth out once design and styling are less global.
    • Styling work was badly named, it involved usability improvements as well
    • Not much to learn from for the next cycle, seems like a one-time problem
  • We agreed on removing issue priorities for features – lower priority issues will be moved out of the milestone instead
  • Design decisions are being made without enough context, sometimes leads to overthinking things
    • not sure who our users are
    • leads to difficulty when deciding complexity of feature
    • Especially tricky for link table dialogue
    • Hopefully access to users helps with this problem
    • This should be our last cycle without access to users

Cycle 6 planning

Work tracking

We’re going to be tracking work in Mathesar! Here’s the relevant table, grouped by due date and assignee

  • As always, the “Assignee” is the owner, responsible for making sure the task gets finished and coordinating with whoever they need to.
    • Don’t have to implement everything, but do have to coordinate
  • We now have due dates for each task (or rather, “due weeks”, they’re all Fridays)
    • Use it for tracking estimates
    • Due date => due week. More granular dates will be too much to manage.
    • Due date in the planning sheet is also for prioritization and time-boxing tasks so that there’s enough time for later tasks.
    • Implementers should update dates in Mathesar after this call.
  • New “Requirements” tasks in Mathesar, this is equivalent to a product spec. Rest of the team should start getting into requirements.
    • Deliverable is descriptions of
      • how the feature will work
      • design work required
      • backend work required
      • frontend work required
    • Kriti will work with the assignees and help
    • Attempting to make things less dependent on Kriti
  • If you see something in the First Release milestone that doesn’t seem relevant, please kick it to a later milestone.
  • Work Type: Styling => implementing the designs. Work Type: Frontend => non-styling.
    • Most of the bugs will be fixed as part of the re-design. Lets keep then as 0% until the re-designs are done.
    • If a new feature needs to be styled, it’s “Frontend” work, not “Styling” work


We need to be accountable for estimates and communicate proactively about delays in work.

  • If you estimate that work will be done in X days and it’s not done by then and you haven’t communicated why it’s taking longer, you come across as unreliable
  • Optimism doesn’t help us plan, and doesn’t help us identify problems
    • If something is taking much longer than planned, we might need to change the plan
  • It’s better to under-promise & over-deliver
  • Takeaways:
    • Make better estimates (include buffer)
    • Communicate proactively in the core-team email list if things are going to take longer
      • Explain why
      • Request help if needed
      • Request change of plan if needed
    • Try to think of due date as a time box
      • reduce scope to fit due date (preferable to moving due date)
  • Brent brought up that due date should come from bottom up, not top down
    • Current due dates are meant as a starting point, implementers should update these to what they feel they can meet
    • We discussed the idea of setting due dates to NULL unless the implementer can commit to them, but the issue is that many of our tasks are defined vaguely and can consume whatever time they’re given
    • Due dates are meant as a time box – e.g. we have a week for live demo work. We could spend a month refining data sets for the live demo, but whatever we can do in a week is probably good enough and that time would be better spent on other release blocking tasks. The due date is meant to convey that.
    • We’re open to other ideas that solve the same problems, but we couldn’t think of any at the meeting.

Coming up in 2023

We’ve been working towards the release for so long, and we’re almost there! Here’s what’s coming up next.

  • First week of January
  • Publicize our release on Hacker News & Reddit
  • Plan out Cycle 2023-01
  • Jan 9 - Feb 3: Cycle 2023-01 (4 weeks) with the goals of:
  • Get our codebase in shape for rapidly iterating on new features and regular releases
    • Includes new git workflow setup (we should start treating master as stable and work off of develop)
  • Get our community work organized to deal with (hopefully) a bunch of new users
    • Includes applying for GSoC 2023
  • Get on the same page as a team about the plan for 2023
    • Brainstorm Mathesar long term vision, business plan, and pitch to funders
    • Plan for sustainabiliy
      • setting up SaaS version
      • offering services / consulting
      • philanthropic funding to cover costs until self-sustainable
    • 2023 feature roadmap – should be fairly flexible and based on user needs
  • Feb / Mar 2023: start pitching potential funders
    • Kriti is already doing a bunch of groundwork for this