-
Notifications
You must be signed in to change notification settings - Fork 524
Revert "Revert "feat(tutor): set up ai tutor courses pilot experiment"" #69728
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Revert "Revert "feat(tutor): set up ai tutor courses pilot experiment"" #69728
Conversation
ed1b700 to
036a74b
Compare
bcbe899 to
8dd81ac
Compare
| extend ActiveSupport::Concern | ||
|
|
||
| AI_TUTOR_EXPERIMENT_NAME = 'ai-tutor' | ||
| AI_TUTOR_PILOT_NAME = 'ai-tutor-pilot'.freeze |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I want to check with @tess323 here because originally, she wanted to re-use this same pilot going forward, but I'm not sure she had strong conviction on that and I'm sort of leaning towards having a fresh pilot at this point, but want to check if there has been any communication with previous pilot participants so far that would make setting up a new pilot / having them re-join a new pilot problematic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, I think we need to start fresh but I will double check at checkin tomorrow. it looked like the original pilot was for teachers enabling tutor per section, but it didn't seem to be wired up anymore?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Im okay with a new name - I cant think of any downside, other than maybe chatting with the few folks who are in there
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there were about 70 in the old pilot when I checked. I'm not sure how they were invited and what their expectations might be, but since the new pilot will be specific to enabled levels and not based on sections (I think this was how it worked in the past?) it seems reasonable to start a new pilot 🤷
8dd81ac to
dcb9db3
Compare
dcb9db3 to
aa4198e
Compare
|
|
||
| interface Window { | ||
| getWebLab?: () => WebLabInstance | undefined; | ||
| appOptions?: { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like appOptions is added to the window object and used in a number of places, but this addition to the global Window interface seems to indicate this is the first time it's used in a TypeScript file. I wonder if there is another way to make this aiTutorAvailable flag available where it is needed as it's generally considered bad practice to add anything to the global window object.
Or is this no longer actually needed (I don't see where this appOptions.level.aiTutorAvailable is actually set) as you mentioned:
I had put it in appOptions (in levels helper) originally due to requirements to check the unit/level there, but those are no longer needed now that we're using the level property.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, I double checked and the level data is not loaded into redux for the legacy labs, they use window.appOptions.level which is set in loadApp.js. I'm also not a fan of using the window object 😬
Or is this no longer actually needed (I don't see where this appOptions.level.aiTutorAvailable is actually set)
it is unfortunately. I moved the check for the user being in the pilot to the current user endpoint but the level setting aiTutorAvailable will still be on appOptions.level
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, is window.appOptions.level of type LevelProperties from apps/src/lab2/types.ts? If so, should we use:
import {LevelProperties} from '@cdo/apps/lab2/types';
Interface Window {
getWebLab?: () => WebLabInstance | undefined;
appOptions?: {
level?: LevelProperties;
};
}
…tinues to show the tutor via query param
…remove unused methods
…ser data stored in redux
aa4198e to
a313fae
Compare
Reverts #69726
This includes a refactor to move
aiTutorEnabledForPilotboolean to the current user api endpoint instead ofappOptions. I had put it inappOptions(in levels helper) originally due to requirements to check the unit/level there, but those are no longer needed now that we're using the level property. So it made sense to move this to a user concern. That revealed that an ai accessible concern already exists, and that there was a previous ai tutor pilot that has since gone stale. The unused methods were removed or refactored to fit the new requirements rather than keeping them around and causing confusion. New methods can always be added for checking sections for tutor enablement in the future.The original pr caused some python lab eyes tests to fail because the ai tutor button and disclaimer stopped showing up in the ResourcesPanel component. Accepting the new baselines actually would have been fine, but instead I added the
show-ai-tutorquery param to the url in the eyes tests to override the need for the level to be enabled for ai tutor and the user to be in the pilot