2023-02-01 Team Meeting

GSoC Project Ideas & Next Steps

Notes

• GSoC deadline: Tue, Feb 7
• Aim to complete project idea documentation by Friday, Feb 3
• Ideas that won’t impact team’s workflow and won’t interfere with other important tasks should be prioritized.
• List of ideas can be found in the email thread
• In general, we should research the ideas from an architecture stand-point to make it easier for contributors.
• Consider the ROI of educating the interns against the value of the output. How much time we invest / what do we get?
• Dom thinks we should try out things (be more experimental) in the projects so that we learn from them.
  • We decided against this because the program is aimed at beginners and it’s better to have clear outcomes.
• Anish likes the concept of extending current features/work
• Anish thinks people will have a preference for easier projects
• Goal is to end up with 10-20 ideas on the wiki for GSoC
• For project ideas, use the template on the wiki.

Current Ideas & Feedback

Moving type inference to SQL (declined)

Brent: We have to be aware of pre-requisites that we have to do internally before an intern can take on this. Once we know how to resolve the pre-requisite it will be ok, otherwise it might be frustrating. Advice is to not do it.

Mukesh: Agrees with Brent on the pre-requisites. Interns will need to understand a lot about the codebase. It might take months.

Anish: most difficult part would be figuring out where the feature fits in product-wise and code-wise.

Casting functions parallelizable

Mukesh: This might be suitable as it requires less understanding of the codebase.

Brent: We have a lot of casting functions, and they are inherently complicated. A deeper understanding might be required.

Table splitting / column logic to DB (declined)

Same as type inference challenges

JSON UI experience

Pavish: It will involve work on the editor, and could increase front-end size. We cannot afford to do that now as it will require architectural work on the front-end.

Sean: Not worried about increase in size of bundle. Doesn’t think it will be architecturally challenging.

Brent: Depends on the scope

Importing data into existing tables UI

No feedback.

Adding summarization functions

Brent: Concerned about this being too easy. Might not last enough to cover all summer.

Kanban view

Pavish: This will take lots of product decisions, discussions, lots of implementation time. Estimate: 6 months, if multiple internal people are doing it. We don’t currently have any visualizations, and that’s going to be tough to get started.

Dark mode

Sean: This is a good one, goal is clear. We want dark mode and people will understand that.

Documenting the component library

Sean and Pavish don’t like it.

Persisting common UI configuration

Kriti: Concerned about the speccing work required.

Pavish: Don’t need to spec architecture, just need to spec requirements.

Refactor store systems & preloading

Kriti: Skeptical about giving a task that starts with “Refactor”

Pavish: We’d need to completely spec it out, then just have the intern implement.

File attachment datatype

Pavish: It depends on how we want the UX to be. Complexity will depend on how sophisticated the features will be.

Brent: nervous if we want front and back end.

Location data type

Pavish: complexity depends on UX.

Brent: nervous if we want front and back end.

Mukesh: Concerned about how quickly we might need this and if we should wait before working on this.

Realtime collaboration

Too big (Brent, Kriti, others agree)

Share tables/explorations publicly

Kriti: If we do this, avoid architectural changes Mukesh: worried about making it indexable

Read-only DB views

If we make the product & UX decisions, this would be an easy / nice intern project (Pavish, Brent agree)

Nominated Projects

After feedback, here are projects we think are worthwhile + the person assigned to writing them up on the wiki.

• JSON editing
  • Sean
• Dark mode
  • Sean
• Importing data into existing UI
  • Pavish
• UI config
  • Pavish
• Location data type
  • Mukesh
• Casting functions parallelizable
  • Dom
• Kanban
  • Rajat
  • May not do this depending on concerns raised after Rajat writes up idea
• DB view support
  • Brent
• API documentation
  • Mukesh
• Summarization
  • Brent

We need more to get to 10-20 ideas total. Everyone is encouraged to write up project ideas. Our discussion today should help with figuring out what kinds of ideas are viable.

Next steps

• People assigned to specific projects will write wiki pages on them by Friday
  • Use the template
• New project ideas should also be put in the wiki by Friday
• Kriti will review ideas on Friday and provide feedback, revisions as needed

Launch plans & update

Notes

• Quick update from Kriti:
  • Website is done, will implement feedback and illustrations
  • Usability testing on website done, usability testing on product in progress
  • Output of product usability testing will be list of potential changes before launch
  • Important: Users and Permissions
  • Important: Installation and Upgrade
  • Set a launch date once we understand the feedback of usability testing (and the resulting scope of needed changes).
  • Demo video is progressing
• Hoping to launch in 3rd week of Feb.
• People are concerned about 3rd week of Feb. launch date.
  • Too much work.
  • Working with potential GSoC contributors is eating up time.
• After launch, we need a process to iterate quickly based on feedback. We’ll need to discuss how to move faster.
  • Defer conversation until launch.