User Story
As a newcomer who has never tried a suggested edit, I want to try a suggested edit, because I'm still learning and want to find simple ways to participate while I learn core wiki skills (and when visiting my homepage, I can see my impact which is motivational and encouraging)
As a more advanced Wikimedian, I want newcomer retention to improve, because the long-term health of the wikis will require new contributors
Design
Illustration assets (from T323785)
| LTR | RTL |
|---|---|
Description
Introduce newcomers who complete ‘normal’ edits to suggested edits. There are two variant for this messaging – the ‘standard’ and an opt-in message. For either option, the criteria for being shown this message will be the same.
For this initial experiment we will only show this message to newcomers who:
- Have Growth features enabled.
- Have never tried a suggested edit.
- A newcomer will only ever see this message twice:
- once they complete a 3rd article namespace edit
- once they complete a 7th article namespace edit
(We may adjust these numbers in the future as we gather more data T322433).
Details:
- Toast message normally shown after editing in VE is shown (not the green success message).
- A message and illustration encourages people to try suggested edits, with a specific opt-in.
- If “Try a suggested edit” is selected, they are taken to the Suggested edits module.
- If “No thanks” is selected, dialog is dismissed.
- Ensure there is no conflict with other products such as the CX tool which has the same suggestion point (see T287025).
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.
