8
Replies
Hi there
I'm not sure how you would envision this working. How many writers? If it's just two or three, you might be able to operate using what I call the "poor man's source control". In that case you each have a full copy of the same project on your local machines. Then carefully coordinate any changes.
Let's say that Alice, Bob and Pat all share working on the same project. Each participant starts off with the same copy. If Alice modifies an existing topic, she notifies Bob and Pat that she is doing so. That alerts Bob and Pat that the topic is being massaged. Once Alice is finished, she sends Bob and Pat a copy of the revised topic. Bob and Pat each copy that revised topic into their own copies of the project so everyone matches.
Same goes if Bob adds a new topic. After adding, Alice and Pat get the new topic and add it to their copy of the project.
No matter how you slice it, there will be hurdles to overcome. As you see in my own example, the hurdles are communicating and lots of copying back and forth. In any type of a source controlled environment, you will ultimately have some form of a "check in" and "check out" process that is involved in playing "traffic cop" and preventing stepping on one another's toes.
Another approach you might consider would be to create a merged setup where each of you are "captain of your own ship" and only ever modify your own projects and nobody ever touches the other projects. The actual merging occurs after generating and publishing.
Cheers... Rick 
Without all logistics' requirements, it's hard to determine solutions! Yet, those depend on available options! 
The collaboration might:
- Comprise two to three writers on two teams, each with its own project of topics. For that scenario:
- A merged setup *might* work - I'll explore it since that's new to me. The only drawback of some concern is adherence to documentation standards between the two projects. I'm envisioning a merged project with too varying a look-and-feel in the output! But, this is an option.
- Comprise multiple writers on one team with one project. For that scenario:
- Some version of source control, coupled with using multi-authoring features as shown here, particularly the first two in the list? (Benefits unclear, since I haven't explored them yet.)
Thanks, Rick!
The merged help method is something that I have used with two other writers. We would each take a copy of the whole merge set up where each project had the same CSS and skin. The skin doesn't matter though as if the user accesses the whole merge, that takes on the skin in the parent. If a child project had a different skin, that would only be seen if that child was opened outside the merge.
It would be agreed which author would work on which child projects and nobody would touch a topic in another child. As lead, the other authors would send me their child projects and I would replace those in the setup on my machine. That just required me to delete the child project I had and replace it with the one sent to me. Then I would generate and publish a new output.
If I made changes to the CSS along the way, I would simply send it to the other authors or use Resource Manager.
Each author needs a copy of the whole merge so that they can create links to topics in someone else's child project. If an author created new topics that other authors needed to link to, then I would update my master as above.
Merged Help is described on my site and the method for Rh11 remains good for Rh 2015.
With discipline, it worked well.
See www.grainge.org for RoboHelp and Authoring tips
UPDATE.
The above is based on WebHelp. It will work for HTML5 but the child projects do not take on the skins (layouts) of the parent. You will need to keep those in sync by some means.
See www.grainge.org for RoboHelp and Authoring tips
The key with responsive layouts is that you must all have exactly the same layout and CSS. If any one writer requires a layout, its CSS or a topic CSS change you have two options:
1] Ensure that everyone copies their project back to you and you update the set, then you make the required change and redistribute the whole merge.
2] Shoot them for failing to adhere to 1. Not recommended.
You may be able to use Resource Manager for some of this but do test that works as I haven't.
See www.grainge.org for RoboHelp and Authoring tips
For the purposes of editing, the lead author (owner) can assign all the projects to others and do no editing anywhere or take responsibility for some of the projects. Your choice. It is not messy for the lead to work on some projects and indeed that is what we did. The discipline is entirely around specific projects only being touched by the person to whom they are assigned.
Author 1 (me) would work on Projects 1, 2 and 3.
Author 2 would work on Projects 4, 5 and 6.
Author 3 would work on Projects 7, 8 and 9.
At various points using File Explorer in Windows I would delete the folders for Projects 4 to 9 in my copy of the merge and copy in the updated projects from Authors 2 and 3. Easy. Just back up as you go.
See www.grainge.org for RoboHelp and Authoring tips
AdChoices