templates
This commit is contained in:
patrick lambret
parent
4eaf425393
commit
9c95429884
|
|
@ -1,27 +1,40 @@
|
|||
### Summary
|
||||
/label ~BUG
|
||||
|
||||
(Summarize the bug encountered concisely)
|
||||
### How is it now?
|
||||
|
||||
(What actually happens)
|
||||
|
||||
### How should it be?
|
||||
|
||||
(What you should see instead)
|
||||
|
||||
### Steps to reproduce
|
||||
|
||||
(How one can reproduce the issue - this is very important)
|
||||
|
||||
### What is the current *bug* behavior?
|
||||
|
||||
(What actually happens)
|
||||
|
||||
### What is the expected *correct* behavior?
|
||||
|
||||
(What you should see instead)
|
||||
Step 1
|
||||
Step 2
|
||||
|
||||
### Relevant logs and/or screenshots
|
||||
|
||||
(Paste any relevant logs - please use code blocks (```) to format console output,
|
||||
(Paste any relevant logs - please use code blocks to format console output,
|
||||
logs, and code as it's very hard to read otherwise.)
|
||||
|
||||
### Possible fixes
|
||||
|
||||
(If you can, link to the line of code that might be responsible for the problem)
|
||||
|
||||
Also please add labels to your bug issue :
|
||||
/label ~BUG ~Reproduced ~Needs investigation
|
||||
If you can, give an estimation of the time needed to fix (in hours)
|
||||
/estimate Xh
|
||||
|
||||
### How to fix a Bug
|
||||
|
||||
1. Ask any question you have in the issue comments before starting
|
||||
1. Create a new branch named issue-${ISSUE_NUMBER}
|
||||
1. Write a test that is failing to validate that this bug exists
|
||||
1. If you can not recreate this bug, feel free to submit just a test with clear name and documentation linking to this issue
|
||||
1. If a test fails indeed, continue to the next step
|
||||
1. Now, when you have a regression test ready - create a fix for that bug
|
||||
1. Write any additional tests if needed
|
||||
1. Document in docstrings in general documentation what was wrong
|
||||
1. Submit a merge request
|
||||
|
|
|
|||
|
|
@ -0,0 +1,71 @@
|
|||
### Feature: `Role or Persona` `Priority` `Objective`
|
||||
|
||||
`Role or persona` What kind of users are we talking about in this particular user story?
|
||||
`Priority` We need to ask users about how important each feature is. Using the MoSCow method to prioritize requirements. This method is based on four main categories: must, should, could, and won't.
|
||||
`Objective` What is the users' final objective by using this feature?
|
||||
|
||||
*Example*
|
||||
|
||||
> Feature: User must log in to access the app.
|
||||
|
||||
#### User story:
|
||||
|
||||
As a `role or persona`
|
||||
I `must/should/could/won't` `goal/need`
|
||||
So that `value`
|
||||
|
||||
*Example*
|
||||
|
||||
> User story:
|
||||
>
|
||||
> As a user,
|
||||
> I must be sent a link to reinitialize password when requested,
|
||||
> So that I can log in and access the app.
|
||||
|
||||
#### Acceptance criteria
|
||||
|
||||
|
||||
###### Scenario-oriented acceptance criteria
|
||||
|
||||
`Scenario` the name for the behavior that will be described
|
||||
- `Given` the beginning state of the scenario
|
||||
- `When` specific action that the user makes
|
||||
- `Then` the outcome of the action in “When”
|
||||
- `And` used to continue any previous statement
|
||||
|
||||
*Example*
|
||||
|
||||
> Scenario: User Forgot password
|
||||
> - Given: The user has navigated to the login page
|
||||
> - When: The user selected forgot password option
|
||||
> - And: Entered a valid email to receive a link for password recovery
|
||||
> - Then: The system sent the link to the entered email
|
||||
> - Given: The user received the link via the email
|
||||
> - When: The user navigated through the link received in the email
|
||||
> - Then: The system enables the user to set a new password
|
||||
|
||||
|
||||
###### Rule-oriented acceptance criteria format
|
||||
|
||||
In some cases, it’s difficult to fit acceptance criteria into the Given/When/Then structure. For instance, design and UX features. Also when visuals exist they should be linked.
|
||||
|
||||
- [ ] item 1
|
||||
- [ ] item 1-1
|
||||
- [ ] item 1-2
|
||||
- [ ] item 1-3
|
||||
- [ ] item 1-4
|
||||
- [ ] item 2
|
||||
- [ ] item 2-1
|
||||
- [ ] item 2-2
|
||||
- [ ] item 2-3
|
||||
- [ ] item 2-4
|
||||
|
||||
*Example*
|
||||
|
||||
> - [ ] Basic new password interface acceptance criteria
|
||||
> - [ ] Password must be > 8 characters
|
||||
> - [ ] Password must contain at least one special character
|
||||
> - [ ] Password must contain at least one upper case letter
|
||||
> - [ ] Password must contain at least one minus case letter
|
||||
> - [ ] Password must contain at least one number
|
||||
> - [ ] Max password length is 255 characters
|
||||
|
|
@ -0,0 +1,27 @@
|
|||
## What needs to be done?
|
||||
|
||||
/estimate Xh
|
||||
/label ~feature
|
||||
|
||||
|
||||
## Technical details
|
||||
|
||||
Are there any technical details worth mentioning?
|
||||
|
||||
|
||||
## Links
|
||||
|
||||
1. Link to user story in wiki
|
||||
1. other related Gitlab issues
|
||||
|
||||
|
||||
## How to complete
|
||||
|
||||
1. How to complete a Feature
|
||||
1. Ask any question you have in the issue comments before starting
|
||||
1. Create a new branch named issue-${ISSUE_NUMBER}
|
||||
1. Implement a simple test to illustrate the desired functionality
|
||||
1. Write some code to complete this task
|
||||
1. Write some additional tests to cover edge cases and some possible errors
|
||||
1. Write documentation about what have you done and why you have done it this way
|
||||
1. Submit a merge request
|
||||
|
|
@ -1,37 +0,0 @@
|
|||
### Problem to solve
|
||||
|
||||
<!-- What problem do we solve? -->
|
||||
|
||||
### Intended users
|
||||
|
||||
<!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later.
|
||||
Personas can be found at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ -->
|
||||
|
||||
### Further details
|
||||
|
||||
<!-- Include use cases, benefits, and/or goals (contributes to our vision?) -->
|
||||
|
||||
### Proposal
|
||||
|
||||
<!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey -->
|
||||
|
||||
### Permissions and Security
|
||||
|
||||
<!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)? -->
|
||||
|
||||
### Documentation
|
||||
|
||||
<!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html
|
||||
Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements -->
|
||||
|
||||
### Testing
|
||||
|
||||
<!-- What risks does this change pose? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? See the test engineering process for further guidelines: https://about.gitlab.com/handbook/engineering/quality/guidelines/test-engineering/ -->
|
||||
|
||||
### 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. -->
|
||||
|
||||
### Links / references
|
||||
|
||||
/label ~feature
|
||||
Loading…
Reference in New Issue