Please see 2022-01-31 weekly planning on GitHub Discussions.
Topic: Functions/Filters API for the frontend - see this issue
Attendees: Brent, Dominykas, Kriti, Mukesh, Pavish, Sean (partial)
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:
This is for Mathesar-specific functionality, examples include:
- Mathesar data types
- “Link Table” APIs
- 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
This is for direct access to PostgreSQL functionality, examples include:
- DB Functions
- 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
- 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.
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
Please see 2022-01-24 weekly planning on GitHub Discussions.
Topic: “State of Mathesar”: Mathesar progress and workflow check in.
Attendees: Brent, Dominykas, Ghislaine, Kriti, Mukesh, Pavish, Sean
Meeting notes follow.
- Current plan is to complete the following milestones:
- Working with Tables
- Initial Data Types
- Working with Views
- UI Styling
- 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.
- 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.
- 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
Skipping these since we talked about them recently:
- Weekly planning discussions
- 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
- 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
- Reduce reviewers
- Schedule meetings ad-hoc (9AM Eastern, 2PM UTC, 10PM HKT)
- Summarize discussions and specs resolved in the weekly planning discussion
- 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.
- 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
- 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 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
- 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.
- 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
- Examples from Creative Commons:
- Who’s interested in mentorship?
- Think about project ideas
- Kriti will make wiki page for them
- 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?
- 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
These are action items across all topics discussed:
- 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
- Update design review process to only include three required reviewers: Kriti, one backend, one frontend. We will rotate through backend and frontend representatives.
- 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
- Submit codebase documentation to wiki via PR
- 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
Please see 2022-01-17 weekly planning on GitHub Discussions.
Please see 2022-01-10 weekly planning on GitHub Discussions.
Please see 2022-01-03 weekly planning on GitHub Discussions.