Abstract Wikipedia/Launch requirements
This is a list of features / capabilities / steps we need to get done before launch. It is probably not complete. An updated version is on Phabricator at phab:T301587.
Design checklist
edit- Creating and editing functions
- Creating function definitions
- Editing function definitions
- Ability to attach and remove implementations and testers
- User testing
- Function page/view function
- Use function widget
- This will need to be thoroughly testing with non-technical people, including the different focus language communities
- Potential to do some user testing in India
- This will need to be thoroughly testing with non-technical people, including the different focus language communities
- User testing
- Use function widget
- Text widget with fallback
- Strings display
- References display
- Object selector / search
- Function call widget
- Names and aliases widget
- Default component to display, create, and edit objects
- Default object page (create, edit, view)
- Main page
- MVP: tiny bit of intro-wording and example of a function call
- Community will take over
- Single language
- Basic search (MVP)
- Reusable search box
- Standard UI
- Mobile friendly (lightly user tested, Polished Design)
- Default component to display objects (MVP)
- Multilingual from the beginning
- Needs user testing
- Needs to work:
- Right to Left
- Non-Roman letter alphabets
- “Long” languages
- We don’t support vertical languages
- Should be user-tested and polished before outreach to non-English speaking communities
- UX for design and implementation of workflows that restrict certain edits
- Documentation of "required" and "recommended" usergroup-level restrictions, for the community to discuss and iterate upon, and allocate to themselves
- Switching from one language to the other
Product checklist
edit- Creation, view, editing of types
- Creation, view, editing of instances of any built-in types (via the default/fallback UX)
- Creation, view, editing of instances of user-generated types (via the default/fallback UX)
- Creation, view, editing, usage of functions (with a bespoke UX)
- Creation, view, editing, and usage of generic types / functions creating a type (via the default/fallback UX)
- Creation, view, editing of instances of generic types
- Creation, view, editing, usage of generic functions
- Viewing and editing of documentation on each object
- Accessibility and discoverability of all content in all languages
- Collect and display metadata for function runs
- Select implementations based on the collected metadata
- Design and implement workflows that restrict certain edits
- Decide which metrics to capture
Tech Checklist
editRoadblocks
edit(These are mostly covered by the Preparing for deployment checklist)
- Security review – We need to undertake and pass (accept) a review before go-live. Needs working with the Security team
- Performance review – We need to undertake and pass a review before go-live.
- SRE Service Ops
- Metrics in place
Internal quality checks
editAutomated testing
edit- All code should wherever reasonable be tested with tests that block merge.
- Unit tests – All code should have comprehensive unit tests. For some areas of the code, this should be enforced with minimum code coverage requirements
- Thresholds and areas TBD.
- Integration tests – All system interfaces should be integration tested
- Browser tests – Key user experience work-flows should have browser tests
- Creating a function
- Viewing an existing function
- Editing an existing function
- Editing the documentation of a function
- Searching for a function
- Using an implemented function
- Recent changes works
- History of an object works
- Diff on history works
- End-to-end tests – Representative, complex, and worrisome areas should be tested via full end-to-end tests.
- Areas TBD.
Code quality
edit- Coding standards – All code should follow current coding standards with each exception documented inline as to why we're violating it.
- Documentation – code is documented
- In-line comments – All inline code TODOs/FIXMEs etc. should be written up as technical debt Phabricator tasks for team prioritisation, which should be mentioned in the comment.
"Good enough" non-functional requirements
edit- Performance – TBD.
- Security – TBD.
- Reliability – TBD.
- Scalability – TBD.
- Integrity – TBD.