#24 Enhancements vs bugs #25
Conversation
| An existing issue is put into `please-test` as the team have finished working on | ||
| it and all of the acceptance criteria have been fulfilled. You, the product | ||
| owner test the issue and on reflection you decide that you think the designs | ||
| would look better with a couple of tweaks - maybe removing the bold on the |
There was a problem hiding this comment.
This makes me think that we could probably do with a flow diagram of what an issue goes through and the various actors.
| fundamentally not what you asked for in the first place or not what was shown on | ||
| the mock-up then they belong in a new issue **NOT** as a 'bug' or as a request | ||
| at the bottom of the existing issue. Small as they seem, these issues are | ||
| enhancements and new scope and they should be dealt with separately. |
There was a problem hiding this comment.
We should look to add an example here of what's an enhancement
readme.md
Outdated
| of times or if there are a few across multiple issues. Not only do the github | ||
| issues become muddied as their title may no longer reflect the content inside | ||
| but also it becomes more complicated for people to follow the chains of | ||
| conversations that have evolved. Also, the extra changes will impact the |
There was a problem hiding this comment.
Got a little cross-eyed reading this big block of text - it could do with some additional highlighting with some boldening of important words and phrases . We know POs are unlikely to read everything here!
dwyl/start-here#118 (comment)
readme.md
Outdated
| ### So what changes count as bugs :bug: then? | ||
| Bugs are places where the acceptance criteria has not been met :negative_squared_cross_mark: : | ||
|
|
||
| ie. you were meant to change the font size across all titles on this page but |
There was a problem hiding this comment.
This comment is a little pedantic, so feel free to ignore it, but strikes me as more of an e.g. than an id est 😊
readme.md
Outdated
|
|
||
| **OR** | ||
|
|
||
| Places where the changes made in an issue have broken something else that |
There was a problem hiding this comment.
Happy to have this in here but it could get messy - if the cancel button colour is changed on another page when you're only supposed to change the cancel button colour on this page, do you open a new bug issue for the other page or do you add it to the current issue which is not relevant to the other page?
readme.md
Outdated
| this example there are 3 actors, the Product Owner (PO), the Scrum Master | ||
| (SM) and the developer (Cleop). | ||
|
|
||
| <img src="https://user-images.githubusercontent.com/16775804/35003068-8d01f586-fae3-11e7-9e35-784092b42d62.png" width=350px /> |
There was a problem hiding this comment.
Thanks for adding @Cleop!
A couple of notes on this:
- It should be the development team that adds the time estimate (sometimes the SM but best practice is really the dev team)
- For step 8, I would suggest that you create a fork in the flow - either closing the issue if satisfied (most likely scenario) or if necessary reporting a bug or opening a new issue
There was a problem hiding this comment.
Worth also adding a link to our contributing process here for anyone who's curious?
|
@iteles - I've added the contributing link, perhaps you can take a look at my redraft of the issue flow? |
#24 Write up about when to create a new issue for an enhancement and when to keep comments in the same issue for a bug