As a Product Manager, I want to disable the Growth control group (in which some users don't receive Growth features on certain wikis), because I believe we have proven the value of the "core" Growth features.
We will continue to test Growth features and conduct experiments (with control groups) for all major Growth features released, but we will no longer have a 20% control group which does not receive Growth features at all.
Description
- Ensure 100% of new accounts created receive Growth features.
- Keep the code that allows for returning to an 80/20 test in the future if we decide an additional experiment is needed.
We love data... so why are we disabling the control group?
- The Growth control group is confusing for Teahouse hosts, Mentors, and others attempting to help newcomers.
- Growth features have been shown to increase newcomer activation and retention.
Impacted Wikis:
- arwiki
- bnwiki
- cswiki
- dewiki
- eswiki
- fawiki
- ptwiki
- trwiki
Note: German Wikipedia requested to have a 20% control group in the past, so we will keep this control group enabled if they prefer. @Trizek-WMF will reach out to determine if they want to keep the control group. If our contacts at German wikipedia agree on ending the control group by our release date, then they will be included in this change.
Acceptance Criteria
- Given I create a new account on any Wikipedia (except German Wikipedia), when the account is created, then I receive the core newcomer Growth features automatically (welcome survey, newcomer homepage, suggested edits, help panel)
- Update deployment table and any other related public Growth documentation (AKA check in with @Trizek-WMF )
Completion checklist
Functionality
- The patches have been code reviewed and merged
- The task passes its acceptance criteria
Engineering
- There are existing and passing unit/integration tests
- Tests for every involved patch should pass
- Coverage for every involved project should have improved or stayed the same
Design & QA
- If the task is UX/Design related: it must be reviewed and approved by the UX/Design team
- Must be reviewed and approved by Quality Assurance.
Documentation
- Related and updated documentation done where necessary
- Internal technical changes: internal repository documentation must be updated (README.md, JSDoc, PHPDoc)
- Infrastructure technical changes: technical changes that reflect on environment, infrastructure, endpoints or any other area of interest for technical contributors should be reflected on Extension:GrowthExperiments or Extension:GrowthExperiments/Technical documentation pages.