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:Ryan Young <ryangyoung -at- gmail -dot- com> To:Rebecca Officer <Rebecca -dot- Officer -at- alliedtelesis -dot- co -dot- nz> Date:Mon, 5 Jan 2015 15:01:29 -0800
We recently underwent a conversion to Agile and have been using the scrum
boards provided by the JIRA Agile add-on. Though it met with some initial
resistance, I think this has greatly simplified our process. Each scrum
team--including our doc team--has its own board and backlog. We've been
creating user stories with the "Story" issue type and epics with the "Epic"
issue type. Creating the backlog has been tricky because production hasn't
fully ramped up yet and there are some major design choices yet to be made.
But we've just used the main development project to create epics and
stories for internal stuff (like implementing DITA!). In cases where we've
actually had working software to document, we've cloned the dev story, and
assigned that clone (edited appropriately) to our backlog. The two stories
can be linked as "depending on" or "following" the dev story (so we can
schedule the doc story for the sprint *after* the dev story); the stories
can also be linked to an epic. We can also create stories for other
products and projects in the same JIRA board.
For the bug/release note conundrum, we added custom fields (on a separate
"Documentation" tab) that dev/suppport/QA can check if a bug requires a
release note. That allows us to track the issue and bug separately.
On Tue, Dec 23, 2014 at 5:12 PM, Rebecca Officer <
Rebecca -dot- Officer -at- alliedtelesis -dot- co -dot- nz> wrote:
> > 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?
>
> I think so, and I seriously hope so. I've emailed our JIRA admin to ask,
> but he's off for Christmas and not back till mid-Jan.
>
> Unfortunately, you're right that JIRA OnDemand can't run that plugin. I
> find it amazing how few plugins OnDemand runs.
>
> Cheers and Merry Christmas!
> Rebecca
>
> -----Original Message-----
> From: techwr-l-bounces+rebecca.officer=
> alliedtelesis -dot- co -dot- nz -at- lists -dot- techwr-l -dot- com [mailto:
> techwr-l-bounces+rebecca -dot- officer=alliedtelesis -dot- co -dot- nz -at- lists -dot- techwr-l -dot- com]
> On Behalf Of Robert Lauriston
> Sent: Tuesday, 23 December 2014 5:52 a.m.
> To: TechWR-L
> Subject: Re: best practices - JIRA fields for the docs team ?
>
> 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
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> You are currently subscribed to TECHWR-L as
> rebecca -dot- officer -at- alliedtelesis -dot- co -dot- nz -dot-
>
> To unsubscribe send a blank email to
> techwr-l-leave -at- lists -dot- techwr-l -dot- com
>
>
> Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit
>http://www.techwhirl.com/email-discussion-groups/ for more resources and
> info.
>
> Looking for articles on Technical Communications? Head over to our online
> magazine at http://techwhirl.com
>
> Looking for the archived Techwr-l email discussions? Search our public
> email archives @ http://techwr-l.com/archives
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Read about how Georgia System Operation Corporation improved teamwork,
> communication, and efficiency using Doc-To-Help | http://bit.ly/1pJ4zPa
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> You are currently subscribed to TECHWR-L as ryangyoung -at- gmail -dot- com -dot-
>
> To unsubscribe send a blank email to
> techwr-l-leave -at- lists -dot- techwr-l -dot- com
>
>
> Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit
>http://www.techwhirl.com/email-discussion-groups/ for more resources and
> info.
>
> Looking for articles on Technical Communications? Head over to our online
> magazine at http://techwhirl.com
>
> Looking for the archived Techwr-l email discussions? Search our public
> email archives @ http://techwr-l.com/archives
>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Doc-To-Help: The Quickest Way to Author and Publish Online Help, Policy & Procedure Guides, eBooks, and more using Microsoft Word | http://bit.ly/doctohelp2015