Skip to content

January 2022 meeting notes

2022-01-31

Please see 2022-01-31 weekly planning on GitHub Discussions.

2022-01-25

Topic: Functions/Filters API for the frontend - see this issue Attendees: Brent, Dominykas, Kriti, Mukesh, Pavish, Sean (partial)

API Goals

We have two different goals for the APIs.

  • Provide necessary abstractions for the front end, e.g. filtering, grouping. This is specific to our front end.
  • Provide low level APIs to interact with database objects and concepts (without Mathesar-specific abstractions)

These goals may necessitate separate APIs. After some discussion, we decided on having two separate API paths:

Abstractions API

This is for Mathesar-specific functionality, examples include:

  • Mathesar data types
  • Filters
  • Grouping
  • “Link Table” APIs

Goals:

  • Limited functionality, strictness, typing
  • Make things as easy as possible for the frontend to work with without knowing much
  • Define things in terms of other abstractions (e.g. Filters should be related to Mathesar Types, not DB types)
  • Dogfood DB APIs

DB API

This is for direct access to PostgreSQL functionality, examples include:

  • Tables
  • Schemas
  • DB Functions

Goals:

  • Broad functionality, doesn’t assume any UI
  • Allow maximum power, focus on flexibility and lack of assumptions
  • Allow DB reflection as much as possible
  • (Eventually) allow composition

What is a Filter?

  • For the purposes of the alpha release, we’re defining filters as anything that can look at a single row and return a boolean.
  • Functions that need global context (other rows or previous functions) do not count as filters
  • “Has Duplicates” is not a filter.

Next Steps

After much discussion, we decided on the following next steps:

  • Dominykas will submit a PR for review that just contains the new functions API and get that merged
  • Dominykas will set up a new PR for replacing current filtering functionality with new filters API, will also move Mathesar Types into abstractions namespace
  • Kriti will create a design issue for “Has Duplicates” not being a filter

2022-01-24

Please see 2022-01-24 weekly planning on GitHub Discussions.

2022-01-18

Topic: “State of Mathesar”: Mathesar progress and workflow check in.
Attendees: Brent, Dominykas, Ghislaine, Kriti, Mukesh, Pavish, Sean

Meeting notes follow.

Alpha release check-in

  • Current plan is to complete the following milestones:
  • Working with Tables
  • Initial Data Types
  • Working with Views
  • UI Styling
  • Deployment
  • Alpha Release
  • Thoughts on how we’re progressing?
    • Working with Tables is mostly done, default value
    • Initial Data Types in progress, taking time (frontend)
    • Working with Views is still being defined, so hard to say
    • functionality first, don’t think of all things DB views can do
    • think of using the views to help user work with data.
    • We’ll do user testing on the alpha release
      • Discussions are open to anyone, but we need to prioritize building core features and might not be able to address user’s input at this point
    • Seem to be moving slow
      • An opportunity to increase speed is to stop trying to implement database concepts with a high degree of accuracy, be more flexible about how we translate db concepts
  • Questions and concerns?
    • FK work should be in a different milestone (not Views). Should move into “Working with Tables”. Still will have it for alpha release.

Upcoming Hiring

  • Does anyone have any thoughts on where we could use more help within the team?
  • We have budget for a couple extra hires.
  • Kriti: need technical writing help. Tutorials, marketing. Could be part time. Community management work too. Content marketer.
    • Sean enjoys this work.
  • After alpha, we might need more frontend work once we have the API more stabilized.
  • Most of the issues we have right now can’t be worked on in paralllel, so additional engineering help may not help at the moment.
    • Applies to both frontend and backend
  • We don’t need another designer at this point either.
  • Maybe someone with real-time colloboration experience when we’re closer to that feature.
  • Might be good to have an intern-wrangler if we’re doing GSoC

Conclusions: No hiring for the next couple of months

Team workflow check-in

Skipping these since we talked about them recently:

  • Weekly planning discussions
  • Standup

Review vs. Focused work balance

  • How do we make sure that everyone has enough time for focused work but specs (for code, design, product), discussions, and code get reviewed speedily?
    • Most of the team is struggling with balancing review tasks with focused work
  • We spend a lot of time having discussions due to turnaround time.
    • Product things are a little subtle, takes some back and forth to clarify, takes so long.
    • Not sure dedicating a day of discussion would fix it because of timezones.
  • Async is helpful to come up with more thoughtful responses
  • Ideas:
    • Days of the week where everyone is focused.
      • e.g. Tue & Thu are “discussion days” and MWF are “focused work”
      • Would exacerbate feedback loop timeline
      • Might be better to have deadline for discussions
    • Maybe we can have discussions at this time of the day (9AM Eastern, 2PM UTC, 10PM HKT)
    • Weekly meeting - reserved time, cancel if needed, be conservative about what added to the agenda
      • Only add things to the agenda if we’ve tried to figure it out async
      • Should this also be only when it’s time-sensitive? Or distracting?
      • Hard to have time to think about the issue and form opinions during sync discussions
    • Don’t seek consensus on everything from everyone (reduce number of reviewers)
      • Frontend code - approved by one of Sean or Pavish
      • Backend code - approved by one of Brent, Kriti, (Mukesh and Dom for small features or non-product work)
      • Design - Assign Kriti + one person from backend + one person from frontend (rotate)
      • Always allowed to review if you have time, but only the person assigned has the responsibility.
      • Latest specs are smaller
      • Product specs - assign everyone since it affects the whole product, less frequent
    • Set short deadlines for reviewing issue descriptions or not at all

Conclusions:

  • Reduce reviewers
  • Schedule meetings ad-hoc (9AM Eastern, 2PM UTC, 10PM HKT)
  • Summarize discussions and specs resolved in the weekly planning discussion

Comms Assignee

  • Lean on the comms assignee more
  • Comms assignee feels like a “cleanup crew”- - it feels like a mistake when they message you
  • Would be nice to have the comms assignee be the point person, they’re expected to ping you, it doesn’t feel like something you’ve missed.

Conclusion:

  • Let’s see how the reduced reviewers work before changing comms assignee. We’ll also have different stuff in our inbox with reduced reviewers.
  • Remove yourself from auto-review-request for PRs if it will be helpful

Async communication improvements

  • Make sure to document decisions.
  • Please provide context when writing questions or comments. Assume your audience hasn’t looked at this for a week.
  • There’s a lot of repetition
  • The GitHub discussion format - can’t see what’s new since last check (replies could be in top-level comments on various threads)
  • Matrix doesn’t have threads.
  • Avoid threads in discussions where possible
  • Reminder that emojis don’t send notifications, so if you want people to know you’ve acknowledged something, also use text.

Code for Japan hackathon planning

  • Code for Japan works on civic projects for Japan. We’re signed up as a project. We want to increase awaerness of Mathesar from within Japan and get more contributors. Will be good prep for GSoC.
  • Workshop to help attendees set up Mathesar locally
  • Mukesh, Pavish, Brent
  • Fill out HackMD document
  • https://hackmd.io/@mathesar/BJa3U4pnY (internal collab)
  • https://hackmd.io/@codeforjapan/SHD35th#2%E3%82%BF%E3%82%A4%E3%83%88%E3%83%AB (real one)
  • Identify issues useful for beginner contributors
  • Mukesh: Maybe we should have more documentation that gives bird’s-eye view of the codebase
    • Document database model, services – what they do
    • Kriti: Technical writer could help with this
    • Kriti: don’t think we need this for the hack-a-thon. Will be more work to maintain until the alpha release
  • Call with Joi already scheduled
  • Mukesh, Pavish, Brent will meet to figure out the HackMD document
  • Pavish will fill in the HackMD details and run them by the team
  • We should get document to Joi by Thursday for the presentation. It should be in English. Joi will translate it to Japanese.
  • Some good content already exists in the Mathesar Google Drive.
  • Should test out development on Windows before the event.

Google Summer of Code planning

  • Links:
  • Application in Feb 2022
  • Will be open to non-students this year
  • This would be our first year doing GSoC
  • Project ideas brainstorm
    • Figuring out how to search through mapping tables
    • Geometric types
    • Suggesting columns to “break out”
    • Breaking out columns to new table
    • Some visualizations? (maybe too core)
    • integrating better text search (via text vectors, etc.)
  • Two lengths of projects: “short”, “long”
  • Projects should:
    • not be core priorities because they might not get finished
  • If accepted, should also set up guides
  • Who’s interested in mentorship?
  • Brent
  • Pavish
  • Mukesh

Action items:

  • Think about project ideas
  • Kriti will make wiki page for them

Team Events

  • How are they going?
  • What would you like to see more of?
  • What would you like to see less of?
  • Volunteers for organizing next few events?
    • Good
  • Figure out how to get to know each other more
    • 1:1 conversations every week
  • Work from the Mathesar 8x8 room during common work times (low pressure)
    • Post when you’re on
    • I’m thinking Fridays (Brent)
  • GeoGuessr was fun
  • CodeNames was fun
  • Kriti will schedule next one
  • Charades

Action Items summary

These are action items across all topics discussed:

  • Kriti
    • Move FK-constraint related tickets to “Working with Tables” milestone and update the deadline
    • Summarize resolved discussions and specs in the weekly discussion
    • Set up project ideas wiki page for GSoC
    • Schedule next two team events: GeoGuessr and Charades
  • Ghislaine:
    • Update design review process to only include three required reviewers: Kriti, one backend, one frontend. We will rotate through backend and frontend representatives.
  • Pavish:
    • Coordinate Code for Japan hackathon planning
      • Fill out HackMD ASAP
      • Identify beginner issues for contributors
      • Plan out presentation before Friday morning meeting with Joi
      • Coordinate testing out Windows setup
  • Mukesh:
    • Submit codebase documentation to wiki via PR
  • Everyone:
    • People should feel free to schedule synchronous meetings to resolve issues, everyone is generally available at 9AM Eastern (2PM UTC, 10PM HKT) on weekdays.
    • Please remove yourself from the appropriate review lists in our code review configuration if you don’t want to review certain types of PRs.
    • Avoid long threads in GitHub PRs and discusions if possible, try to keep everything in the main body.
    • Schedule 1:1 conversations with other members of the team to get to know them better, maybe one a week.
    • Please think of Google Summer of Code project ideas

2022-01-17

Please see 2022-01-17 weekly planning on GitHub Discussions.

2022-01-10

Please see 2022-01-10 weekly planning on GitHub Discussions.

2022-01-03

Please see 2022-01-03 weekly planning on GitHub Discussions.