-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
When to create a new issue when dealing with bugs and enhancements #24
Comments
Image to add for an example of what should be a new issue #25 (comment): Made for #25 (comment): |
I'm going to look into if I can find one from BEP. These are some examples but they're not very clean: @iteles - what do you think? or @nelsonic do you have any good examples you can think of? |
These are all super round the houses and have in some cases a weird process generally. The nice thing about this private issue is that it's a really good example of when a new issue should be opened and how easy it is to just keep tacking things onto the end of an issue, despite being closed source 😬 Only one I can find with this kind of interplay is https://github.com/emfoundation/ce100-app/issues/893#issuecomment-338958544 but also not quite as clean as the above. |
Maybe this comment onwards @Cleop ? https://github.com/emfoundation/ce100-app/issues/947#issuecomment-341501841 |
POs may wonder if they have feedback or thoughts on an issue whether they can add it to the existing issue or whether they should create a new one, here's a little guide to determine what to do:
When to create a new issue when dealing with bugs 🐛 and enhancements 🎀
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 title, making the logo a bit bigger and changing the copy by a few words. What do you do in this situation?These changes might relate to the changes made in the issue but if they are 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.
Why?
These kinds of small changes add up, especially if you change your mind a couple 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 developer's initial time estimate which is damaging for their accuracy when trying to estimate how long issues will take. Imagine if these small changes prevented another issue in the sprint from being able to be completed which had you put the changes side by side, you would have prioritised the existing issue over these small tweaks. It's fine if you do want to prioritise getting these changes made but do it in a new issue where the time and importance can be seen by everyone and changes can be made to remove another issue from the sprint if prioritising this new one has to push another one out.
So what changes count as bugs 🐛 then?
Bugs are places where the acceptance criteria has not been met ❎ :
ie. you were meant to change the font size across all titles on this page but you missed out the last title - please can you change it?
OR
Places where the changes made in an issue have broken something else that previously worked 💔
ie. you changed the colour of submit buttons but that's also changed the colour of the cancel button, please can you fix the cancel button and make it the colour it was before? 🔧 ✨ ❤️
The text was updated successfully, but these errors were encountered: