Tags

New release v0.7.2:
- Fix validation issues
- Add OKRs as a table in the database accessible via /okrs endpoint for the frontend
- Update wikis to filter out private editability

New release v0.7.1:
- Follow up dates validation
- Update experiment/instrument start/end time to 14:30 UTC
- Fixed additional padding for icons

New release v0.7.0:
- Added instructions to update canonical-data submodule before running xLab
- Form validation fixes
- Added validation for dates

New release v0.6.9:
- Updated Name form component
- Fixed margin for the main error message

New release v0.6.8:
- Fix start + end dates with UTC noon time in database
- Replaced skipWhen with omitWhen to omit validation rules
- Minor fixes to forms

New release v0.6.7:
- Update api response to set time to UTC noon

New release v0.6.6:
- Added better validation to forms
- Expand domains in /api/v1/experiments?authority=varnish response
- Update CI config

New release v0.6.5:
- Added better validation to forms
- Expand domains in /api/v1/experiments?authority=varnish response
- Update CI config

New release v0.6.4

- Add and update traffic and variations field sets

Version 0.6.3

- Reduced logging verbosity

Version 0.6.2:

- Invalidate api routes not explicitly specified 
- Update analytics + base experiments endpoint

New release v0.6.1:
- Backend refactored as ES modules
- Sample rate has been update to percentages
- Fixed query for analytics config API response

- npm package security updates
- Add query parameters to experiments endpoint
- .env file updates
- Add lodash as dependency

Address Design Review feedback points 1, 2, 3, 4, and 9 from https://phabricator.wikimedia.org/T390036#10748263, namely:
- For some reason, I can't make the tooltip that clarifies the meaning of the "Split" indicators to be displayed. Would it be possible to trigger it when the split span is hovered?
- [Control] The suggested copy for the Control group's description was: "The control group represents users who receive the existing experience. It serves as the benchmark for measuring the impact of the changes being tested.". Does this proposal sound good?
- Variation module: To avoid redundancy, the "Machine-readable name" and "Description" sections don't need to be included in the Variantion module. The corresponding fields will already display this information.
- Variation module: Thanks for incorporating the clever machine-readable placeholder suggestion! It works amazing. I would just recommend that we also only display the "e.g.," bit when users enter a value in the "Variation name" field. I think this would avoid any potential temporary confusion. Does that sound good?
- Since they are purely decorative (unlike the ones included in interactive elements), would it be possible to apply a lighter color (color-subtle) to the user-avatar icons?

New release v0.5.6:
- Migrate from features to variations:
   Switch from features (AKA feature variants) - pairs of names and boolean values - to variations/groups. Variations can have:
      - A name (required)
      - A machine-readable name, which is the sluggified name (required)
      - A description (optional)

New release v0.5.5:
- Fixed the alignment for human and machine-readable name
- Added a workaround to use feature name as groups

New release v0.5.4:
- Removed warning message from instruments form

New release v0.5.3:
- Update requirements for EPIC
- Fix wrong base stream names
- Fix multiselect lookup readonly functionality
- Minor fixes

New release v0.5.2:
- Fix logout link

New release v0.5.1:
- Upgrade to Node.js v20