TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
So carried away talking about business processes and workflow that I forgot the question at the bottom of Kevin's e.
The answer is yes, rarely.
In all our cases the decision that it is an 'internal' note is made by at coding stage. They have been trained to include a reason - this saves then time later so it was not hard to do. Then when the Support consultant looks at it, they might disagree and think there is something we need to communicate to clients. They don't change it, they discuss it with the TA and come to agreement. They can involve me, or not. Typically the support consultant would write up the change, then complete their stage of the task and then it would go to Documentation and I would review it as per usual.
I should add that the support consultant is part of the sprint team. A group of them rotate from their usual support duties to being on the team and that takes them about 50% of their time.
Cheers, Diana
-----Original Message-----
QUESTION: Do you ever get Jira Issues that must change from "Include in Release Notes = NO" to "Include in Release Notes = YES" ?
If so, how is that handled, late in the game, when several people/roles have already handled and passed the issue onward, before it had specific content meant for Release Notes?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
New! Doc-to-Help 2013 features the industry's first HTML5 editor for authoring.
