I allows you to not clutter every screen with information you might just need when creating the issue. An example is a bug-issue type where you might just want to have a summary, version and description of the issue. As the case goes into research you might want to expose a worklog, and as you close the issue the summary and description of the issue should already be correct and you might add fields that allow you to retrospect over the issue to evaluate your own work, and how you could have done it better. While editing, editing most of these fields might be useful or not.. It just to be able to fit every organization.
Imagine I have a field named Root Cause that is used when a bug is fixed to describe what caused the bug.
I won't know what value to use in that field when I create a Bug
So there is not much point in having the Root Cause field on the Create screen for a Bug
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
As part of the Bitbucket product team I'm always interested in better understanding what kind of impact the use of our tools have on the way you work. In a recent study we conducted of software devel...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs