Definitely in the wrong forum - you want Source Control.
We don't use source control. I am talking about putting the compiled help files in a network folder and having links to the program.
When you talk about "housing your RH projects" - that's source control. What it sounds like you want is "Can I use JIRA to host my WebHelp output?" I would say, go ahead & try it - not sure how it would work or what it would look like - but no harm, no foul for experimenting...
Would someone who has actually done this please comment?
I have not actually "done" this but I have used JIRA. How we used it was to create a "JIRA ticket" for every change we wanted to make to the documentation. We outlined what we wanted to change, what wording we would use, what pages / topics were impacted, etc. I know we added links as URL to other folders and websites within the ticket. That said, we were maintaining our help system on Confluence so we didn't have a need to "host" a help system within JIRA.
We are not going to do JIRA tickets for each change. That is very time consuming and adds a lot of time to each help edit. We figured that we would spend one day a week doing JIRA tickets. Totally not worth it.
I am interested in the fact that you maintain your help system on Confluence. Can you give me more details on how that works?
The value we saw in it is that we (previously) did not have a tracking system for the changes we made to the documentation and a JIRA ticket was intended to create a process for those changes. We would make changes and then, after some time passed, we would have vague recollections for why we made a change, but struggled to provide concrete details. Using JIRA provided that mechanism.
Send me an email (prhmusic at hotmail dot com) and I'll send you a link to the Confluence site I worked on.
A method I tried seemed to work OK provided it is carefully managed.
At the beginning of a topic add the information about the change. Apply a specific style to it so that it appears red or some bright colour, then apply a condition.
When you hand over the output for testing, leave that text in as it helps the testers see what has changed and approve it.
After it has been signed off, regenerate the help with the information excluded using a build tag.
The important things are to make sure the versions are managed so the developers don't issue the wrong version and to use wording that would not embarrass you if it did go out. Not something like "Rewritten as it was a load of ********.
See www.grainge.org for RoboHelp and Authoring information
Peter - that's a great idea about using a condition! I might go another step and create a SSL for Printed Documentation so a "manual revision" notice could be generated.