Skip to content

2023-02-01 Team Meeting

GSoC Project Ideas & Next Steps


  • 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


  • 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.