Re: Using jira for documentation development workflows

[Helen OBoyle <hoboyle -at- gmail -dot- com>]

Shawn,

And yes, we also had the same situation as Diane, regarding developers
wanting to close issues before documentation was done, which is why we
didn't simply go with a development workflow that included a stop at
"Documentation" before resolution.  Pretty much we just have to watch the
structures for development projects, and watch JIRA issues created by
support and QA that are not included in structures, and insert our own
related documentation issues, as needed.


On Sat, Jul 12, 2014 at 9:40 AM, Helen OBoyle <hoboyle -at- gmail -dot- com> wrote:

> Hi,
>
> We use JIRA Structures to define groups of related issues (tech, doc,
> marketing, etc.) which include at least one documentation issue, for
> documentation issues that are synchronous with development projects (new
> features, bug fixes, module refactoring).  We also have other documentation
> issues that aren't part of a structure, because they're not related to a
> current development project, which are things like doc bug fixes, misc
> content edits, pre-JIRA backlog tasks, etc.
>
> We use a custom workflow for DOC- tasks, with DOC-related statuses like
> Peer Review, Reviewed (Peer), Editing (Peer), SME Review, Reviewed (SME)
> and Editing (SME), that allows us to track items through the peer review,
> revise as needed and then send for SME review workflow that we use.
>
> We use labels to "tag" issues into related groups and then manage the
> resulting collection of issues with dashboards containing queries of these
> and other fields such as project, tech writer, status, etc.
>
> Unfortunately, I wasn't on the team when the workflow was designed, so
> they left out a crucial pre-review status -- that of "Awaiting action by
> non-doc-team member."  My choices appear to be, to assign the task to
> someone else and create a query that just pulls every task "open" with me
> as tech writer that is not assigned to me, or to commit the sacrilege of
> prefixing the issue title with "PEND", the name of the individual, a "why"
> and the age of the request, and to toss them all in the "Drafted" queue I
> rarely use to hold drafts (because as soon as I consider something "Draft"
> I also consider it reviewable).  So right now I have issues like "PEND
> M.SLATER Q 27 JUN - Write description of parameter Frequency" in my Draft
> queue.  One reason I didn't choose the first option was that assigning
> tasks to devs and PMs ended up being the equivalent of tossing them into a
> black hole.  THEIR dashboards specifically look at their current dev
> projects, and not random items assigned to them by other people in the org,
> so even if I sent them an email, the task would too quickly fall off their
> radar and mine.
>
>
> On Sat, Jul 12, 2014 at 6:04 AM, Shawn <shawn -at- cohodata -dot- com> wrote:
>
>> Kevin (et al),
>>
>> I noticed that you mentioned "Jira" and "documentation" in a single
>> thought. Kind of a rarity, it seems.
>>
>> I changed the subject so that I am not hijacking the other thread. :)
>>
>> Being the sole tech writer in a hard-core Linux engineering team, Jira is
>> pretty central to all the development work here. Unfortunately, the
>> current
>> Jira configuration doesn't really meet my documentation workflow
>> requirements. Additionally, I have found very little about this subject on
>> the Web.
>>
>> Can you/anyone offer advice (or web URLs) on how best to use Jira for
>> technical writing?
>>
>> Thank you,
>> Shawn
>>
>>
>> On Mon, Jun 23, 2014 at 12:00 PM, McLauchlan, Kevin <
>> Kevin -dot- McLauchlan -at- safenet-inc -dot- com> wrote:
>>
>> > Starting from a history of waterfall-ish development, and after more
>> than
>> > two years in-progress, we are in water-agile-fall(**), trying to get to
>> > agile, and one outcome of that is that EVERY new thing I add to the
>> docs is
>> > supposed to be captured as some kind of Jira issue (story, bug,
>> task...).
>> >
>> > So, I never used to ask permission, and now I still don't, directly, but
>> > the indirect effect is that that's how it now works.
>> > I have (as we say around here) a whack of issues in my backlog that
>> aren't
>> > assigned to any sprint, that aren't supposed to be implemented unless
>> I've
>> > got nothing to do.  That doesn't happen, of course.
>> >
>> > In reality, they'll get snuck into a DOC sprint that we writers are
>> > assigning to ourselves, packed among structural and other sanctioned
>> > stories and issues.  But I thought I'd check which way the winds blow
>> for
>> > the rest of y'all*.    :-)
>> >
>> > (*I'm not southern - I just like to say "y'all" sometimes)
>> > (**actually, some product teams, here, are frighteningly agile, while
>> > others are still getting onboard - I'm in two that are at different
>> places
>> > along that spectrum; if I had rhythm, you could call what I do
>> "dancing"...
>> > but no )
>> >
>> > -----Original Message-----
>> > From: techwr-l-bounces+kevin.mclauchlan=
>> safenet-inc -dot- com -at- lists -dot- techwr-l -dot- com
>> > [mailto:techwr-l-bounces+kevin.mclauchlan=
>> > safenet-inc -dot- com -at- lists -dot- techwr-l -dot- com] On Behalf Of Mike Starr
>> > Sent: June-20-14 6:39 PM
>> > To: techwr-l -at- lists -dot- techwr-l -dot- com
>> > Subject: Re: What is not mandated is forbidden
>> >
>> > I never ask permission to put something into a document that can not
>> only
>> > help the user but help reduce support queries. If you ask permission,
>> > you're just telling them to say no. Had you just put it in there chances
>> > are good it wouldn't have been flagged as "out of spec".
>> >
>> > Best Regards,
>> >
>> > Mike
>> > --
>> > Mike Starr, Writer
>> > Technical Writer   -    Online Help Developer   -   WordPress Websites
>> > Graphic Designer - Desktop Publisher - Custom Microsoft Word templates
>> > (262) 694-1028   -  mike -at- writestarr -dot- com   -  http://www.writestarr.com
>> > President - Working Writers of Wisconsin http://www.workingwriters.org/
>> >
>> > On 6/19/2014 12:14 PM, McLauchlan, Kevin wrote:
>> > > Does everyone subscribe to the notion that customer docs should
>> contain
>> > only what is necessary?
>> >
>>
>> --
>> *Shawn Connelly*
>> Technical writer
>>
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> Read about how Georgia System Operation Corporation improved teamwork,
>> communication, and efficiency using Doc-To-Help | http://bit.ly/1lRPd2l
>>
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>> You are currently subscribed to TECHWR-L as hoboyle -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
>>
>
>

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Read about how Georgia System Operation Corporation improved teamwork, communication, and efficiency using Doc-To-Help | http://bit.ly/1lRPd2l

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -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