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

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.

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