Research: "Edit me" icon/action that imports data into a feature template
What problem(s) will it solve?
What problem do we solve? Try to define the who/what/why of the opportunity as a user story. For example, "As a (who), I want (what), so I can (why/value)." The barrier of entry for users to know how to change a KSAT is currently very high. As a user, I want to be able to quickly and easily recommend changes to KSAT's, so I can more easily provide feedback to CYT and document my requirements as a user.
Who is the intended user(s)?
Who will use this feature?
Anyone trying to modify a KSAT
Lay out the expected user experience
What is the single user experience workflow this problem addresses?
Given that a user has located a KSAT they want to modify, When a user clicks on the "Edit me" action icon or trigger, Then they should be brought to a template which has populated all of the information about that KSAT, And they can then indicate which elements of information they want to change more easily.
Proposal
How are we going to solve the problem?
- We need to research if we can pass information from a link into a issue template (or figure out if importing this information is even possible).
- If we can't use Gitlabs build in template functionality... can we build a gui/form that would use the Gitlab API to create and issue with the information we'd like?
- Can we think of another way to make modifying KSAT information easier for all users?
Further details
https://gitlab.com/90cos/mttl/-/requirements_management/requirements 1 states we shouldn't put KSAT data into a database so that limits some options.
Permissions and Security
What permissions are required to perform the described actions?
Anyone logged into gitlab should be able to create an issue and the issue would be submitted as the logged in user (if an API call is made for example).
- Anonymous contributions should not be allowed
Documentation
Update User Documentation
- If intuitive enough, we should strive to reduce "how to edit a KSAT" burden (including less documentation)
Update Developer Documentation
- Should identify the method/mechanisms used to ensure maintenance is understood
Update CYT Overview briefing
- Update overview slides relevant to this feature.
Availability & Testing
just user testing
What does success look like, and how can we measure that?
Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this.
Success Criteria:
- We've improve the frequency at which we receive changes
- We grow the number of authors which submit changes
- We reduce the amount of time necessary to process and approve these changes
Acceptance Criteria: TBD