2022-01-05 release planning meeting

Meeting Owner: Kriti Attendees: Entire core team

Tracking work & comms

Time: 10 min Desired outcome: We decide on a process for tracking release-related work and we each understand it.

Sean has proposed tracking work using smaller GitHub milestones instead of using a Mathesar table. Milestones would have associated deadlines.

• Pros: Work tracking is not duplicated
• Cons: May be harder to see the release as a whole

Kriti is also proposing using the mathesar-developers list for most email unless it NEEDS to be private.

Pre-meeting prep

Please write down your opinion about the proposals. If you don’t have an opinion, that’s fine, write that down.

• Anish: did not attend meeting
• Brent:
  • I’m fine with using smaller GH milestones. I agree that using the developers mailing list is best.
  • Reply to Kriti: for dogfooding: If we’re serious about offering a hosted version, that will be plenty of dogfood (after a fashion)
• Dom:
  • I’m in favor of trying to not duplicate work tracking (I ran into some confusion caused by the duplication); I also don’t want to update the Mathesar table every day (but I do update the Github issues as part of my workflow); no opinion on mailing list to use;
• Ghislaine:
  • Agree with using GH milestones
• Kriti:
  • Using only GitHub milestones would be less work for me and makes sense, although I would like to find something other use case to dogfood Mathesar
• Mukesh:
  • I am fine with GH milestone and mathesar-developers email.
• Pavish:
• I have no major concerns with using GH milestones. I use the table in Mathesar to get an idea of progress as a whole, which also lets me know if someone is available to help me with/pick up tasks. Only using GH makes that harder.
• +1 for using mathesar-developers list for most emails.

• Rajat:

  • Strong agree for GH milestones. Gives me a better view of what all I have created a PR for and what all work is left for me. I do not have to regulary update %ages(which mostly are inaccurate). Plus a single place for me to track progress and read issue details is definitely less messy.
  • Agreed on using mathesar-developers list for most emails.

• Sean:

  • Milestones: ✅
  • mathesar-developers: ✅

Notes

• Seems to be general consensus around using GH milestones
  • We’ll use those. Kriti will set them up
  • Need volunteers for helping triage - Sean volunteered
  • Not everything needs to be in specific milestones
  • We can pull from the larger milestones into granular weekly milestones
  • We are not deleting current milestones yet
  • Global view will be in the GH project
• Regarding dogfooding
  • Waiting for documentation to be finished so we can set it up on our own servers and test installation
  • Sean imagines some system where instead of syncing between GH issues and projects, we could sync between issues and mathesar
    • Replacement for projects
    • customizable
    • GitHub doesn’t support multi-repo milestones so this would be useful
  • Mukesh imagines using Mathesar for error logging
    • Kriti: But will this use case help make Mathesar better for our target users?
  • Further dogfooding discussion was put in the parking lot
• Mailing list
  • Please default to developer mailing list
  • Core team list only when things need to be private
  • Rule of thumb: “business” discussions are private, everything else is public

Release approach & goals

Time: 30 min Desired outcome: Each person in the room should understand the broader goals and approach to our release. The goals and approach should be finalized.

The work we need to do before our first release:

• Get website & live demo ready for usability testing
• Perform usability testing on website & live demo
• Get installation, upgrade, and associated documentation ready for testing
• Get people to test installation workflow
• Get product ready for usability testing
• Perform usability testing on product
• Complete users & permissions
• Fix issues resulting from all testing - website, product, documentation
• Work on marketing & launch prep
• Work on legal prep (e.g. privacy policy)
• Publish release

(we also need to work on our GSoC application in this time period)

Goal of first release:

• Launch on HN & selected subreddits
• Get users!

Goal after first release:

• Work with users to make our product useful
• Launch hosted version

Initial milestones:

• Get website & live demo ready for usability testing
• Get product ready for usability testing
• Get installation, upgrade, and associated documentation ready for testing
• Complete users & permissions

Pre-meeting prep

Do the tasks and plan above make sense? Are we missing anything? Are there additional things that we should work on?

• Anish: did not attend meeting
• Brent:
  • What’s meant by ‘complete’ users and permissions? I think we should scope that; Are there missing pieces that are blocking release?
  • I think ‘upgrade’ needs to be separated from ‘installation’ in our minds (maybe it already is, but the merged bullet point worries me).
• Dom:

  • Launch hosted version

    • Hosted means self-hosted here?
  • When do we plan to do the first release? There’s probably not a hard-set date.
• Ghislaine:
  • Plan looks good to me.
• Kriti:
  • N/A, since I wrote everything above
• Mukesh: - They make sense. Don’t have any opinions.
• Pavish:
  • They make sense to me.
  • I can’t think of anything we need additionally.
• Rajat:
  • Makes sense to me.
  • The previous email sent by Kriti does not talk about the timelines around fixing issues found in usability testing. I understand that is because we do not know what those issues are as of now(until we do the usability testing). Rest all is good.
• Sean: ✅

Notes

• installation/upgrade/deployment
  • A bit muddled
  • Most of these don’t involve frontend work, only upgrade does
  • We’ll clarify requirements for this next week sometime
• usability testing
  • Use a service that crowd-sources usability testing
  • Set up tests, give tasks, look at videos
  • Task-oriented rather than general
  • Need to make sure we have time to fix problems that we find
• Launch timing
  • We haven’t set a launch date yet because we’re not sure how much time it’ll take to fix things
  • We should not launch later than the end of Feb. Earliest could be end of Jan
  • The milestones “01. First Release” and “2023-01 Public Launch” will both get sorted into weekly milestones to be completed before the launch
• Documentation testing
  • Find someone with relevant experience from upwork and ask them to install using the docs
• Users/permissions
  • We can parallelize with usability concerns
• Need to put together GSoC org application
• Next goal after launch: sustainability
  • SAAS more reliable than consulting
  • According to external advice, consulting can be arbitrarily complicated and isn’t commonly a revenue generator, distracts from core product work
• Hosted version
  • Need more staff (Kriti agrees)
  • Need to really focus on performance
  • Need to differentiate ourselves from others doing hosted versions
  • Kriti has done some early modeling to try determining a pricing structure, but it’s too early to share now
  • Want this to be feasible by EOY
  • Need to make sure that the hosted version will be good enough that people will pay for it, so core product should be made useful for real users before hosted version
• Nature of milestones: Feature vs. Timeline
  • Timeline is needed
  • Weekly sprints
  • We’ll keep using the GH project to track the “Feature” for each ticket
  • First milestone starts next week

Work assignments

Time: 10 min Desired outcome: Everyone knows what they’re working on for the initial milestones, milestones have appropriate deadlines, AND everyone understands what completing the milestone entails.

• Get website & live demo ready for usability testing - DEADLINE Jan 13
  • Website design:
    • Ghislaine
  • Website copy:
    • Kriti
  • Website frontend help:
    • Pavish
  • Data sets:
    • Brent
    • Dom
    • Pavish + Ghislaine (if needed to smooth data set loading experience)
• Get product ready for usability testing - DEADLINE ???
  • Frontend:
    • Sean will triage first release and public launch milestones
    • Sean will do this triage work ASAP, then we’ll figure out a deadline for addressing all the outstanding tickets
  • Backend: May not need anyone, TBD, Mukesh is the logical person since otherwise he’s working on a lower priority goal.
• Get installation, upgrade, and associated documentation ready for testing - DEADLINE Jan 20
  • Frontend:
    • Sean
  • Backend:
    • Mukesh, Dom, Brent
  • Design:
    • Ghislaine
• Complete users & permissions - DEADLINE ???
  • Requirements: Pavish
    • Deadline will be determined after Pavish works on requirements
  • Frontend: Pavish, Rajat, Sean
  • Backend: Mukesh on standby

Action Items

• Kriti will create weekly milestones in GitHub
• Sean will triage existing issues
• Kriti will set up meeting to clarify installation / deployment / upgrade requirements