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