2023-11-22 staff check in¶
Team check in¶
- Working on transition stuff
- Sam rotating out, Kriti/Adam taking over
- Main things working on:
- New US payroll platform
- New international contractor platform
- Lots of annoying administrative stuff
- Working on docker compose file for installations
- Need to set up custom domain for testing
- Working aligning documentation with the new docker compose file changes
- Less work time this week due to personal stuff
- API documentation project has been ended because it’s too much work to get it to completion, associated communication
- DB connection endpoints - for 0.1.4 release
- Some experimenting with RPC standards, not ad-hoc
- Not worth the time right now to do proper RPC
- DRF action endpoint instead
- last week, had first design session
- working on bulk linking (many to many)
- exploring different options
- Discussed some options with Brent
- A lot of things were cleared up on a technical level
- Will discuss with Pavish next
- preparing results of bulk linking discussions for next design sessions
- Next, moving on to other usability issues
- Monthly ticket planning meeting could be for design/prioritization?
- Probably do this in a separate meeting
- Sean has lots of thoughts about the many-to-many problem, will be away for the next week, wants to be involved
- Monthly meeting Sean’s organizing is to be a “Product Approval” meeting
- Connected to new GH workflow
- Wants to have the meeting just for product approval, separate from prioritization
- Sean and Ghislaine will have a call to discuss these meetings
Last week mainly focused on org transition.
- Board meeting
- Administrative and IT work
- 1:1s and unblocking work as needed
- User call
- Mathesar for Scrabble tournaments
- We’ve received the first installment of the grant
- Org name change in process
- Mathesar Foundation, Inc.
- Board voted on Wednesday to change name
- Filed with MA
- Now waiting for response
- After that, we need to change name with bank, etc.
- New board: Sam, Ian, Kriti + board treasurer Adam
- Kriti is CEO
- Focusing on admin work for the next few days
- Product/strategy work after that
- I was out sick for a couple days, so progress was slower than usual.
- The PR to replace typesafe-i18n with svelte-i18n was reviewed and merged.
- I raised a PR to add django translations and instructions for maintainers.
- I spent some more time thinking about automation and translation workflow. My suggestions are below, we can discuss this async.
- Went through multiple open-source repos to find their degree of automation, including: CC-legal-tools-app, CiviCRM extentions, Django-docs.
- Their main automation is around pushing translations for a particular branch and automatically syncing with that branch. We already have this.
- None of them have branch level sync between git repo and transifex. I attempted a POC to implement this, but then I decided against it:
- Transifex only allows one branch per project (not per resource) for open-source projects. We cannot implement a branch-level sync with our repo without upgrading to Premium.
- Even if we did have Premium, the effort needed to implement this is high and doesn’t seem worth it.
- As mentioned above, I haven’t found other open-source project that seem to have implemented this.
- Translation workflow:
- Not having branch level sync limits our options, which actually makes our workflow simpler.
- The resources within Transifex should always be considered ‘prod’ resources.
- They will be linked directly to one of our branches, either the ‘develop’ branch, or the ‘master’ branch. I prefer the
- Whenever translation files in the branch changes, our automation scripts will push the changes to Transifex and when they are translated and reviewed to about 50%, it will pull them into our repo. We could also run this as a daily sync operation.
- Release process:
- We pull all translated files into develop (automation should take care of this).
- We make a release branch, which should contain all translations from develop.
- If we make changes/fixes in the release branch, we should merge the changes into develop, and then merge the translation commits into the release branch.
- We do not wait for missing translations after we freeze the release branch. If we want translations, we will wait until they are present in develop, before freezing the release branch.
- Translating the app
- I will be doing this inbetween my other tasks, throughout the upcoming week.
- DB connections
- I will be working on the DB connections home page. I had a chat with Sean on Friday, and went through the requirements. I haven’t begun work on it yet, I will be starting on it tomorrow.
- Migration script cleanup
- I haven’t begun work on it. I will start it when I have the time in the upcoming week.
DB connections work
- I’ve proposed some adjustments to our GitHub process. I’m actually really excited about this. I think it’s going to help move our tickets along better.
- I spent lots of time cleaning up GitHub tickets, particularly ones marked as “draft”. Much of this cleaning work, though “completed” is yet to be actually “pushed” (so to speak) to GitHub. Basically I have a bunch of lists of tickets that requires specific label changes, and I’ll be applying these changes en masse after my workflow proposal is approved.
- I’ve also prepared a queue of tickets to discuss at December’s product approval meeting
Misc. team workflow issue discussion¶
We should set up regular calls to discuss the following:
- Product specs
- This could be like the “design sessions” but focused on “product specs”?
- Permissions / architecture
- Implementation specs
- Product strategy
- Higher level
- User research & help check-ins
- Community growth / contributors, etc.
- beta planning work
We already have calls for
- Ticket review
- Design sessions
- What frequency should each call be?
- Who should be involved?
- Who should facilitate?
- Should we still have the weekly meeting?
Meetings based on ticket needs
- Covered by repo admin process - no meeting needed
- Product approval
- Covered in monthly ticket reviews
- Implementation specs
- We’ll do a one-off meeting during weekly meeting on the 6th and see how that goes
- UX design
- Covered in design sessions
- Technical approval
- User feedback
Meetings based on other needs
- Kriti will facilitate
- Everybody should attend
- First iteration in December, figure out cadence
- Product “big picture” meeting
- “Big Picture”
- E.g., workspaces
- Once a week
- Pavish will schedule / facilitate
- At the end, discuss what we’ll talk about next
- Everyone should attend
- deferred until January
- Community growth meeting
- One in December to talk about GSoC
- Further cadence decided then
- User research & help check-ins
- Deferred until January
- We have enough info for the strategy now
- It’s okay to lose some users now to focus on long term stability
Decision making process¶
We want to avoid everyone being involved in every decision.
We should set up “areas of responsibility” with no more than 2 people per area. Decisions should be made by people with responsibility. Everyone else is welcome to observe or provide input. If a decision involves multiple areas, we will union the people involved.
e.g. bidirectional navigation did not need to involve backend
What areas and owners can we identify now?
We agreed that this is a good idea. Kriti will follow up via email with an initial list of areas and owners.
Task management workflow¶
Quick update: Kriti will be working on this. We might just try Basecamp and see how that goes.