When one of our a customer issue tickets is resolved and passes QA, I'd like to have a ticket created automatically in a separate project (Documentation) so that development can close/resolve their issues separately from the documentation specialists, and the new ticket can be reviewed to see what (if any) documentation updates are necessary. My experience with the "Create on Transition" plugin is that it will only make a sub-task within the same project. Is there a way to have Jira (using CoT or some other plugin or method) automatically create that separate ticket and assign it to the appropriate project?
You have to make the documentation as part of the Agile flow. It cannot live outside of Agile. You have to do it inside the Jira ID (Bug or Story) You can use Sub-task OR create documentation field(s) inside the Jira form and transition screens. You cannot create a new Jira ID for Docs and link it to the Bug or Story, the Developers will not go to it. I have tried several ways and I ended up with this method.
I purchased a module from a company called GetCider (getcider.com) called Dynamic Documentation. This product uses Dynamic Forms and JQL queries to automatically create HTML Release Notes in real time. I love this product and every team said it has made their documentation task so much better.
There are fields that the Developers fill out regardless if the Jira ID needs to be documented or not and is REQUIRED. The fields are called Developer Notes and is best practices. This information is used by QA for testing and the Product Owner. This should be required information for QA to properly test. These fields feed into the Release Notes and are modified for external viewing when added to the Release Notes by the Developer, QA and Product Owner.
For Bugs the fields are…
Developer Notes: Affected Areas
Developer Notes: Impact Analysis
Developer Notes: How Dev tested it
Developer Notes: Root Cause
The Product Owner, Developer or QA Engineer answers the question “In Include in Release Notes” Y/N When they select Yes they select the type (Fixed Defect, Known Issues, Enhancement, Limitation or New Feature. The JQL query will pull this into the specific area of the HTML Release
We configured the JQL query to only display Closed items. Now that we made it part of the workflow and the QA Engineer should do a final scrub of the Release Notes. The Technical Writer will review once the Jira ID is Closed. The Product Owner owns the full feature description.
The Developers, QA and Product Owners are documenting each Bug or Story as the move them through the workflow and the Technical Writers do the final review, audit and corrections.
You need to define what goes into the Release notes as this responsibility is now everyone. For example
Fixed Bugs in Release Notes
Fixed Bug is Linked to a Support/Field issue
Fixed Bug changes UI or functionality
Fixed Bug changes UI or functionality
Known issues or limitations
NON Closed Bug linked to a Support/Field issue
NON Closed Bug is NOT Linked to AND the Severity is Critical or High AND is pre-existing or introducing with the Release
Non Closed Bug with new features(s) should be demoed and agreed upon with the Product Manager
I can’t go into all of the features of the GetCider tool (Dynamic Release Notes) but it has solved some big headaches for us.
I’m a designer on the Jira team. For a long time, I’ve fielded questions from other designers about how they should be using Jira Software with their design team. I’ve also heard feedback from other ...
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