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.
Re: best practices - JIRA fields for the docs team ?
Subject:Re: best practices - JIRA fields for the docs team ? From:Robert Lauriston <robert -at- lauriston -dot- com> To:TechWR-L <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Mon, 22 Dec 2014 08:51:37 -0800
That's a nice trick. If the UI field is initially "no" and at some
later date you change it to "yes," does the docs issue still get
created automatically?
Probably irrelevant for me since we use JIRA OnDemand and it can't run
most plugins.
On Sun, Dec 21, 2014 at 3:18 PM, Rebecca Officer
<Rebecca -dot- Officer -at- alliedtelesis -dot- co -dot- nz> wrote:
> We get a separate DOCs issue for each docs-affecting software issue, automatically. Software issues have a field that asks whether they changed the user interface behaviour. If the software engineer says yes, JIRA automatically creates a Docs issue and links it to the software issue. That way you don't have to worry about the engineers remembering to make a Docs issue. This is done through a free JIRA plugin called Groovy Script Runner.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Read about how Georgia System Operation Corporation improved teamwork, communication, and efficiency using Doc-To-Help | http://bit.ly/1pJ4zPa
