2022-02-28 weekly planning

[kgodey]

About

At the start of each week, we start a discussion covering Mathesar's progress, team member check ins, and general updates. Everyone is welcome to add a new topic to discuss or to comment on existing topics.

Discussion topics

• Last Week in Mathesar
• Frontend priorities
• Backend priorities
• Design priorities
• Product priorities
• Comms Assignee schedule
• Google Summer of Code prep
• Dominykas' check in
• Sean's check in
• Kriti's check in
• Brent's check in
• Ghislaine's check in
• Pavish's check in
• Mukesh's check in

Weekly check-in

@centerofci/mathesar-core please post your weekly check-in as a top-level response and edit the discussion topics above to add your check in as a topic. Others are also welcome to respond.

Prompts:

• How did your most recent work go?
• What are you planning to work on soon?
• Do you anticipate any dependencies or blockers that someone else on the team can help you with?

If you'd like to add anything else to your check-in that's not related to the prompts, feel free to do so.

[kgodey]

Last Week in Mathesar

Feedback Requested

• Specs:
  • [DRAFT] Update number type to support custom currency format mathesar-wiki#36

Complete

• Milestones:
  • 2022-02 improvements with 8 issues complete
• Discussions:
  • Which column identifier should we use for DDL operation #1081
• Specs:
  • Add initial spec for handling dates and times mathesar-wiki#35
• Wiki updates:
  • The Mathesar types engineering page was renamed to UI Types (and the text was updated throughout to refer to "UI types") to keep the nomenclature consistent with our code.
  • The Product Spec for Views has had major updates, but isn't complete yet.
• Full stack and general work:
  • Finish adding E2E tests #1062
• Backend work:
  • Datetimes to RFC 3339 #1088
  • Implement display options for Duration type #1091

[kgodey]

Frontend priorities

1. Complete front end changes to Mathesar 896 Change records api parameters to use column id instead of name #1047
2. Complete Improve UX when adding new records to a table with a NOT NULL column #775
3. Get open draft PRs complete and merged:
   1. Menu components #1076
   2. Text type & basic Boolean type frontend implementation #1080
4. Make progress on issues from the Initial Data Types and 2022-03 improvements milestones. Some ideas:
   1. NumberInput component improvements #970
   2. Provide a clearer visual distinction between edit mode and select mode #927
   3. Wait until user is done editing a cell before saving #928
   4. Blur via keyboard after entering edit mode on a NULL cell should cancel edits #929
   5. Add keyboard shortcuts for setting a cell to NULL #936
   6. Frontend implementation for non-Mathesar data types #659
   7. Frontend implementation for Boolean Mathesar type #257 (assigned to @pavish)

@pavish @seancolsen Please comment below with thoughts/concerns.

[seancolsen]

Looks good. With the difficulty I've had thus far in predicting the time-to-completion of my refactoring project, I'll refrain from continuing to make such predictions. But I'll say that I think I'm really really close to completing it!

[pavish]

Looks good to me.

I would like to schedule improvements with regards to editing the table after we have basic data type frontend implementation completed. Each type has different interactions and would possibly require some refactoring, building these improvements over existing code might result in more code to refactor. This includes some suggestions mentioned above:

• Provide a clearer visual distinction between edit mode and select mode #927
• Wait until user is done editing a cell before saving #928
• Blur via keyboard after entering edit mode on a NULL cell should cancel edits #929
• Add keyboard shortcuts for setting a cell to NULL #936

[kgodey]

Backend priorities

The frontend is catching up fast to the backend, so we really need to get backend work for Initial Data Types completed and start on Links between Tables ASAP.

We divided up the issues as follows:

1. @dmos62:
   1. Filtering:
      1. Get open PRs merged:
         1. Add URI and text filters #1079
         2. Add email filters #1087
         3. Add filters for time types #1089
         4. Add filters for money and boolean #1090
         5. Hint system improvements #1098
         6. Introduce some filter aliases for time types #1101
      2. Other filtering issues:
         1. Resolve logic duplication in the db.types namespace #1100
         2. Suggest popular/standard URI schemes as values for appropriate filter parameters #1097
   2. Data Type API updates::
      1. Get open PRs merged:
         1. Split datetime into three UI types #1093
      2. Work on issues:
         1. Inconsistent database type name casing in backend code #1036
         2. Add database type alias information to database type endpoint #1037
2. @mathemancer:
   1. Final updates to Spec for human readable date and time parsing #845
   2. Custom money type #1094
   3. Grouping:
      1. Implement grouping for Text types. #408
      2. Implement grouping options for the email type #411
      3. Implement grouping options for the URI type #414
      4. Implement range based grouping for numeric types. #384
      5. Implement grouping options for date & time types #429
      6. Implement grouping options for money types #419
      7. Implement grouping options for duration type #432 (currently blocked)
3. @silentninja:
   1. Replace column name usage with ID:
      1. Get Mathesar 896 Change records api parameters to use column id instead of name #1047 merged
      2. Replace column index usage with attnums and Column model id #839
         1. Column selecting operations should use attnum #992
            1. PR: Replace column_index usage in column selection operations with column_attnum #1104
         2. Column dropping operation should use attnum #993
         3. Column alteration operations should use attnum #994
         4. Column creation and copying should use attnum #995
      3. Remove column_index from MathesarColumn class #996
   2. Ensure that we can set, get, and delete default values for all types #1064
      1. PR: Test Cases to Ensure that we can set, get, and delete default values for all types #1103
   3. Implement display options for the custom Money type #1105 (currently blocked)

I'll also work on #1008 if I have time this week.

@dmos62 @mathemancer @silentninja Please comment below with thoughts/concerns.

[kgodey]

Design priorities

1. Money type design updates #1063 is top priority since it's blocking backend work.
2. Exploratory wireframing for Design for visual query builder ("Data Explorer") #1065
3. Design discussions for Design for List data type #978

@ghislaineguerin @ppii775 Please comment below with thoughts/concerns

[ghislaineguerin]

@kgodey Looks good. I have already coordinated the weekly check-in's w/ @ppii775

[kgodey]

Product priorities

1. Finalize product spec for Views.
2. Updates to the GitHub issues for Views design to conform to the spec.

[kgodey]

Comms Assignee schedule

Week	Person
2022-02-28 to 2022-03-04	Brent
2022-03-07 to 2022-03-11	Kriti
2022-03-14 to 2022-03-18	Pavish
2022-03-21 to 2022-03-25	Mukesh
2022-03-28 to 2022-04-01	Sean
2022-04-04 to 2022-04-08	Dominykas
2022-04-11 to 2022-04-15	Ghislaine

Instructions

You can also find the schedule and instructions for the Comms Assignee on the wiki page. Please feel free to update the wiki page if you think of anything useful during your shift.

[kgodey]

Google Summer of Code prep

Google Summer of Code organizations are going to be announced on Monday, Mar 7 (in one week). If we do get selected, we will have an influx of people looking for issues to contribute to. We need a bunch of good first issue and help wanted issues. Also, the Comms Assignee should expect to be spending more time on comms.

It would be great if everyone could take an hour this week to look through our issues and:

• make sure the existing good first issue and help wanted issues look good.
• create any new good first issue and help wanted issues that you can think of.

[dmos62]

How did your most recent work go?

Nothing out of the ordinary. Progress seemed smooth.

What are you planning to work on soon?

See filtering PRs merged. Work out new tasks that stem from discussions of those PRs (I've been trying to make large requested changes in new PRs).

Go on to data type API updates after that.

Do you anticipate any dependencies or blockers that someone else on the team can help you with?

No.

[seancolsen]

Sean's check in

How did your most recent work go?

• Not so great. In preparation for moving the front end to use column ids, I got sucked into a refactor that has ended up being way more involved than I predicted. Once we get that work merged and the dust settles a bit, I think it will be good for @pavish and I (and perhaps @kgodey too) do do some retrospective analysis on our process. I'm hoping this refactoring will be worth it in the end, but it doesn't feel in-line with our current goals of prioritizing features.
• The good news is that some of the other recent front-end architectural improvements (i.e. TS strict, Prettier, E2E testing) has made this refactoring work quicker/easier than it otherwise would have been.
• There are still a couple nagging architectural issues that have been slowing me down though, and I plan to discuss them with @pavish on a sync call at some point (though it's lower-priority).

What are you planning to work on soon?

• Finish my refactor. To aid review, I'm planning to open a PR against master with this work (instead of tacking it all in Mathesar 896 Change records api parameters to use column id instead of name #1047 which originally motivated this work).
• Add front end changes Mathesar 896 Change records api parameters to use column id instead of name #1047. I want to base those changes on the work already in Mathesar 896 Change records api parameters to use column id instead of name #1047 and the refactoring work that I'd like to PR against master. I'm open to suggestions for the best workflow. Unless I hear otherwise, I'll probably do my work locally on top of cherry-picked commits, then cherry pick my work into a public branch once my refactoring work is merged into master (and thus can be cleanly merged into Mathesar 896 Change records api parameters to use column id instead of name #1047).

Do you anticipate any dependencies or blockers that someone else on the team can help you with?

• Nope.

[kgodey]

I think it will be good for @pavish and I (and perhaps @kgodey too) do do some retrospective analysis on our process.

I'm happy to be involved in this if you think it would be be helpful.

I'm open to suggestions for the best workflow.

Why not open the refactoring PR, work on something else until it is merged, and then merge master into #1047 and go from there? If you'd like to use your refactoring work in the "something else" you're working on, you can base that on top of the refactoring branch since you won't need backend work from #1047 in it.

[seancolsen]

@kgodey

work on something else until it is merged

Cool, will do.

[kgodey]

Kriti's check in

How did your most recent work go?

I did get a significant amount of work done on specifying formulas for the Views product spec, but I'm not done yet. I spent too much time in meetings last week (>10 hours in a 4 day week) to be able to get much focused work done (especially in addition to reviews, discussion, etc.) I'm rearranging my schedule so I have fewer meetings each week.

What are you planning to work on soon?

My list is the same as last week with the additional task of looking through our contributor-friendly issues:

• Complete work on the Views product spec
• Spend some time working on good first issue and help wanted issues
• Open a new discussion for Views product spec review
• Update design tickets for Views based on product spec
• Set up style guide and tooling for consistency in backend code #1008 if time permits

Do you anticipate any dependencies or blockers that someone else on the team can help you with?

Nope.

[mathemancer]

Brent's check in

How did your most recent work go?

The week was productive, but initial types is starting to feel like Zeno's Milestone. We're down to fiddly details there, and every time something is solved, we seem to discover more that needs to be done.

What are you planning to work on soon?

Once I get the custom money PR submitted, I need to tidy up and add a few details to the date/time spec while I still remember them. Then on to grouping.

Do you anticipate any dependencies or blockers that someone else on the team can help you with?

Nothing at the moment.

[kgodey]

initial types is starting to feel like Zeno's Milestone.

It's always been the biggest milestone in the roadmap, there's so much to do for each type. I expect a lot of issues to be closed this week, there's a number of pull requests in review. I expect that someone on the backend team can move on to the next milestone next week.

[ghislaineguerin]

How did your most recent work go?

It went well. Regular check-ins with Kriti are helpful to unblock design work. Money-type related discussions during the team meeting were also helpful in resolving the spec updates.

What are you planning to work on soon?

#1065

Do you anticipate any dependencies or blockers that someone else on the team can help you with?

None

[pavish]

Pavish's check in

How did your most recent work go?

Pretty well! Text type implementation is ready, along with groundwork for possible cell types with varying interactions. The same PR also contains basic boolean type implementation without display_options.

What are you planning to work on soon?

• Complete boolean type support
• Number component improvements
• Number type frontend implementation

Do you anticipate any dependencies or blockers that someone else on the team can help you with?

None at the moment

[silentninja]

How did your most recent work go?

It was quite slow, as I had a runny nose and couldn't concentrate much. Though it is taking longer than I expected, the issues are nearing completion, so not much to fret about.

What are you planning to work on soon?

• Finish issue Replace column index usage with attnums and Column model id #839 and related sub-issues
• Implement display options for the custom Money type #1105
• Start working on issues in Linking tables milestone

Do you anticipate any dependencies or blockers that someone else on the team can help you with?

None