CLaM Meeting Discussion Ideas

[BenHenning]

Overview & instructions

Starting in 2025, the Core Learner and Mastery team is adjusting its meeting format to be more collaborative and widely applicable to all members of the team. This entails two main things:

1. Primary discussions in the weekly meeting will encompass topics of general interest such as show-and-tells, tech talks, announcements, and more.
2. Discussions to debug or work through a specific problem people are facing will be done in a follow-up weekly "office hours" with the team leads.

This comment tracks all potential discussion topics for upcoming CLaM meetings, and the corresponding person who will conduct them. We aim to have 1-2 of these each week. If you're interested in discussing topics that you'd like to see or would like to contribute, please reply to this discussion thread.

Plans for the next CLaM meeting

The current topics planned for the next CLaM meeting (on 7 January 2025) are:

• TBD

Future discussion topics

The different types of discussion topics include:

• Show-and-tells: these are quick demos meant to simply show what someone is working on. They can include 1 or 2 areas that the presenter is looking for feedback on,but this isn't a requirement. This is also not a formal review of ongoing work--the point is simply to share progress with the team. :)
• Informal technical discussions: these are (mostly) unplanned discussions around a particular idea or solution. This isn't a time to debug a particular issue, nor is it a fully fledged tech talk. There is a primary person who may have a list of subtopics to discuss, but they're essentially providing an open discussion prompt for the team.
• Tech talks: these are more detailed talks meant to teach something in depth. They should include a slide deck and very likely will be recorded so that other members of the team (including future ones) can benefit from them.
• Announcements: these are significant team/Oppia changes or milestones that are useful for helping to continue building context of the CLaM team's work among the broader Oppia and education ecosystem.
• Bug break-down: these are collaborative work sessions where we go through a single issue and work to disambiguate it by digging into the potential root causes and potential solutions. The goal here is to essentially construct starter issues from less detailed bug reports or other issues to help onboard new team members.
• Games: not exactly a discussion prompt, but it's something fun to do together.

Show-and-tells

• New profile selection list changes being done as part of the onboarding v2 project by @adhiamboperes.

Tech talks

None requested yet!

Informal technical discussions

• Discuss how to debug GitHub Actions by @Rd4dev.

Announcements

None planned yet!

Bug break-down sessions

• Drag & drop is slow to respond on slow devices
• Bazel Linter Integration

Games

None requested yet!

[TanishMoral11]

Hey @BenHenning ,
Could you please add issue #3000 to the list of discussion topics? It involves setting up Buildifier with GitHub checks and pre-push hooks, and could be relevant for an upcoming meeting.
Thank you!

[BenHenning]

Thanks for bringing this up @TanishMoral11. It's actually less important than it seems. We already integrate with buildifier. #3000 is simply recommending that we move the check into Bazel proper rather than using static_checks.sh (which is also true for other checks like ktlint, buf, and Java checkstyle). I have a PR I started a long time ago that introduces a single replacement for static checks (with progress checking and nice colorizing) that should address #3000, but fortunately it isn't urgent. :)

[manas-yu]

I wanted to provide an update on this issue (#4996) following this comment. I’ve identified and implemented a solution that resolves the build errors caused by the default Windows encoding, and the build is now working fine.

Given that we’re in the Gradle phase-out stage, I’d like to discuss whether we should proceed with these changes or hold off. Should this be prioritized, or would it make sense to defer?

Additionally, while this solution addresses the immediate problem, I believe implementing a .gitattributes file remains important. It’s a good practice for ensuring consistent encoding and line-ending handling across the repository, which will benefit contributors in diverse environments.

[BenHenning]

I agree with your point that it's still important, but likely less urgent to implement due to Gradle no longer being an option for development.