Update Android project descriptions for GSoC 2025 #445
Conversation
Small fix to project 4.1's details, as well.
Some small spacing adjustments in projects 4.1 and 4.2, as well, for consistency.
|
PTAL @seanlip for approval. PTAL Adhiambo and RD for your respective projects (but please also look at all three projects and let me know if you notice anything odd). |
|
|
||
| This project entails introducing a developer-only UI (as part of the developer options section of the app) which displays all platform parameters and feature flags in the app, their current enabled/disabled status (for feature flags) or values (for platform parameters), and their sync status (i.e. whether they're being synced from the server or using a local developer default). It also allows an explicit manual override to force the feature on or off, or to override the platform parameter's value. | ||
| This project entails introducing a developer-only UI (as part of the developer options section of the app) which displays all platform parameters and feature flags in the app, their current enabled/disabled status (for feature flags) or values (for platform parameters), their sync status (i.e. whether they're being synced from the server or using a local developer default). It also allows an explicit manual override to force the feature on or off, or to override the platform parameter's value. |
There was a problem hiding this comment.
@BenHenning why did you drop the "and" in the first sentence?
| @@ -1119,18 +1120,18 @@ We also recommend taking up at least one checkbox item from each of the followin | |||
|
|
|||
| **Project Description:** | |||
|
|
|||
| When learners make a mistake on a concept they have previously demonstrated in an earlier part of a lesson, it often makes sense to redirect them back to an earlier card to try and reinforce earlier concepts that the learner may have not fully understood. However, with the current implementation, learners subsequently need to re-answer all the cards between the earlier state and the state they had reached, which is frustrating. | |||
| When learners make a mistake on a concept they have previously demonstrated in an earlier part of a lesson, it often makes sense to redirect them back (or to a parallel flow) to try and reinforce earlier concepts that the learner may have not fully understood. However, in the current app implementation, learners subsequently need to re-answer all the cards between the earlier state and the state they had reached, which is frustrating. | |||
There was a problem hiding this comment.
Suggest replacing "back (or to a parallel flow)" with "back to an earlier card" -- I think that's the main case that we're trying to fix here.
| @@ -1221,52 +1259,211 @@ This project entails introducing a developer-only UI (as part of the developer o | |||
|
|
|||
| **Related issues:** | |||
|
|
|||
| _(Note: Specific issues will be added soon.)_ | |||
| Issues related to portions of the codebase that will be affected by this project: | |||
| - [#46](https://github.com/oppia/oppia-android/issues/46) - Note that this is a great issue that has smaller chunks that can be done in isolation to build familiarity with the developer workflow menu. | |||
There was a problem hiding this comment.
What do you mean by "great issue" (do you mean "good to tackle" or "big in size")?
| - Updated UI tests for the new functionality. | ||
|
|
||
| - The new screen fully supports overriding various platform parameters and feature flag values. | ||
| - Support for force downloading flags from Oppia web (i.e. by calling PlatformParameterController.downloadRemoteParameters and ask for an app restart). |
|
|
||
| <details> | ||
| <summary>Org-admin/tech-lead commentary/advice</summary> | ||
|
|
||
| This project involves introducing a new, isolated user interface that only affects developers (and possibly testers or user study facilitators in the future) which means it doesn't require the same level of gating as regular learner-facing features. It's often nice to work on brand new UIs, as well, since everything is starting in a fresh, clean state rather than building on existing complexity and tests. | ||
|
|
||
| The domain side of platform parameters isn't trivial to understand, but it's straightforward to explain and analyze the dataflow. This is expected to be a straightforward project that balances domain and frontend work (with a majority of the work being UI-related). | ||
| The domain side of platform parameters isn't trivial to understand, but it's straightforward to explain and analyze the dataflow. This is expected to be a straightforward project that balances domain and frontend work (with a majority of the work being UI-related). Expect to spend a lot of design time during the proposal period working to understand how parameters and flags work, especially with regards to their plumbing and related code generation. |
There was a problem hiding this comment.
The two halves of the first sentence "The domain side ... analyze the dataflow" sort of contradict, might be worth clarifying that (doesn't "being able to explain and analyze the dataflow" imply some reasonable level of understanding)?
| <details> | ||
| <summary>Suggested PM demo points</summary> | ||
|
|
||
| - Milestone 1: The new UI correctly shows all platform parameters and feature flags, and their correct value and sync statuses. | ||
|
|
||
| - Milestone 2: The new screen fully supports overriding various platform parameters and feature flag values. | ||
| - Milestone 2: The new screen fully supports overriding various platform parameters and feature flag values. This includes demonstrating both overriding user flows in the new UI, and showing the value changes correctly take effect in the app after a prompted (and accepted) app restart. |
There was a problem hiding this comment.
I read the second sentence as: demonstrating (a) overriding user flows in the new UI, and (b) showing that value changes correctly take effect in the app.
Is that what you meant by the "both" part? Or, did it refer to "the two overriding user flows"? If the latter, what are those "two overriding user flows" -- do you mean overriding feature flags and overriding platform parameters? (I initially sort of thought of them as one flow, so just wanted to clarify that's what this meant)
If the last interpretation is correct, then a suggestion is: "This includes demonstrating the user flows for overriding feature flags and overriding platform parameters in the new UI, and showing that the value changes correctly take effect in the app after a prompted (and accepted) app restart."
|
|
||
| Scripts usually seem like straightforward changes, and they often can be. However, they almost always uncover unexpected complexities that need to be solved mid-project (which is why this is considered a more difficult project overall). It's also the case that many of the lint issues that are included as part of this project may not have known solutions ahead of time which requires additional problem solving that may occur after the design phase of the project. | ||
|
|
||
| That being said, there are many examples of both scripts and exemptions to reference when designing and constructing the script itself. While the exact functionality being implementing (wrapping the Android linter and creating an intermediary step between the exemption XML and a textproto version of it) isn't well defined, the other boilerplate of a script (textproto loading, script library, running scripts in CI, etc.) is well defined and referenceable. |
There was a problem hiding this comment.
Second sentence might be wrong ("While the exact functionality being implementing") -- should it be "implemented"?
Perhaps say: isn't well defined yet (and should be explained clearly in your proposal)?
| <details> | ||
| <summary>Suggested PM demo points</summary> | ||
|
|
||
| - Milestone 1: Demonstrate the script can be run locally to catch lint issues. Demonstrate that the script runs on develop, and is passing. Demonstrate that the script runs for pull requests and can catch a lint issue potentially being introduced by the pull request. Show the exemptions file being used. |
There was a problem hiding this comment.
| - Milestone 1: Demonstrate the script can be run locally to catch lint issues. Demonstrate that the script runs on develop, and is passing. Demonstrate that the script runs for pull requests and can catch a lint issue potentially being introduced by the pull request. Show the exemptions file being used. | |
| - Milestone 1: Demonstrate that the script can be run locally to catch lint issues. Demonstrate that the script runs on develop, and is passing. Demonstrate that the script runs for pull requests and can catch a lint issue potentially being introduced by the pull request. Show the exemptions file being used. |
| <details> | ||
| <summary>Suggested PM demo points</summary> | ||
|
|
||
| - Milestone 1: Demonstrate the script can be run locally to catch lint issues. Demonstrate that the script runs on develop, and is passing. Demonstrate that the script runs for pull requests and can catch a lint issue potentially being introduced by the pull request. Show the exemptions file being used. |
There was a problem hiding this comment.
Why do you need the "potentially" in the second-last sentence? Not sure what that entails.
What does "Show the exemptions file being used" mean -- maybe say "Show that exemptions listed in the exemptions file are not reported."? (Or, should we still report them in the logs as FYIs, but make them non-blocking?)
|
|
||
| - Milestone 1: Demonstrate the script can be run locally to catch lint issues. Demonstrate that the script runs on develop, and is passing. Demonstrate that the script runs for pull requests and can catch a lint issue potentially being introduced by the pull request. Show the exemptions file being used. | ||
|
|
||
| - Milestone 2: Demonstrate X types of lint issues have been fully resolved (i.e. by demonstrating that the linter is running for those checks, no exemptions for those types of issues exist, and the script passes). Verify that each category of issue is properly caught by demonstrating the linter catching these failures if reintroduced in the codebase. |
There was a problem hiding this comment.
What does X mean, or how is it determined?
| - Set up initial tests to demonstrate that the UI displays correctly. | ||
| - Display a list of platform parameters and feature flags from a Developer Options menu, along with their current values and sync statuses. | ||
| - Set up initial tests to demonstrate that the UI displays correctly. | ||
| - The new UI correctly shows all platform parameters and feature flags, and their correct values and sync statuses. |
There was a problem hiding this comment.
It seems like the PM demo points might have been repeated here and below, outlining the same technical requirements again.
| - Updated UI tests for the new functionality. | ||
|
|
||
| - The new screen fully supports overriding various platform parameters and feature flag values. | ||
| - Support for force downloading flags from Oppia web (i.e. by calling PlatformParameterController.downloadRemoteParameters and ask for an app restart). |
There was a problem hiding this comment.
The force download option isn't included in the mocks yet.
Just to confirm the requirement: I assume it's simply an action to fetch from the web without a separate UI to list remote values. Displays a toast on completion and a restart alert on back navigation. Also, it only updates the remote DB with the latest values while preserving local overrides.
| - Build the app and install it on a local device or emulator. Then verify that you can (a) build a non-test library target locally, (b) run a unit test locally, and (c) play through the app locally. | ||
| - Write new Kotlin code with unit tests. | ||
|
|
||
| **Related issues:** |
There was a problem hiding this comment.
oppia/oppia-android#5169 tracks known lint categories
This revises the following parts of the Android project descriptions for GSoC 2025:
Note that the tracking issues for projects 4.2 and 4.3 still need work (4.1 should be in a good place)--I plan to take care of that later this week.