Workflow for production of User Guides

Quoting from the Document/Development page on the wiki:

1. Create draft doc, upload to Drafts space for relevant book.
2. Reviewer checks out draft doc, makes changes with tracking on,
    checks doc in, promotes to Reviewed space.
3. Author (or someone else, depending on book & circumstances) revises
    draft, removes change tracking up to that point, demotes file to
    Drafts space -- OR skip to Step 5.
4. Repeat Steps 2 and 3 as needed.
5. When ready, author (or other) promotes file from Reviewed space to
Copyediting/Proofing space.

     When I look at the Repository, I only see three folders for most
books: Draft, Proofing, and Published. There is no Reviewed nor Feedback
folder. So, presently how are the folders used at the present time and
in what order?
     How much trouble would it be to create the additional two folders
for each of the books in the Repository?
     Instead of clicking "Submit for review" and moving the draft file
into the Proofing folder, is there another process that could be used?
Perhaps another folder called "Peer review" since it is being reviewed
by ones peers?
     Thinking this might be the sequence: place the doc into the Peer
review folder in step 1, reviewed by someone and placed in Feedback
folder in step 2, Author revises the draft placing it again in the Peer
review folder for further review in step 3 (or skip to step 5), and then
repeat steps 2 and 3.
     
--Dan

Hi,

When I look at the Repository, I only see three folders for most
books: Draft, Proofing, and Published. There is no Reviewed nor Feedback
folder. So, presently how are the folders used at the present time and
in what order?
    How much trouble would it be to create the additional two folders
for each of the books in the Repository?
    Instead of clicking "Submit for review" and moving the draft file
into the Proofing folder, is there another process that could be used?
Perhaps another folder called "Peer review" since it is being reviewed
by ones peers?

The wiki is out of synch with the folder structure now on Alfresco.

The Alfresco structure for each documentation is, as you say, Draft,
Proofing, and Published. New work goes in Draft. When the work is
done, you "Submit for review" and it gets transferred to Proofing.
Someone reviews the doc in proofing. If it's publication-ready, you
send it to Published. If not, you reject it and send it back to draft.

I chose that because it was simple. It would be possible to create the
additional two folders, but then the simple workflow designed and
implemented would no longer work and would need re-implementing.

At the time, I chose the current workflow because it was simple and I
didn't really see the need for more complexity. Of course, that can be
changed. But is it *really necessary*? What advantage would be
procured? Those are the questions I asked myself at the time...

I agree with you. I just did not know if we were going to change
the Alfresco structure of the documentation.
     I want to think about it some and perhaps come up with a suggestion
for the documentation to match what we are now doing. So, if I do this,
should I post my suggestions to this mailing list or edit the
documentation by inserting them with my name?
     I think you will find that I will have quite a few questions so
that I can understand what is going on. Once in a while I might need
someone to tell me to "read the manual" which is fine as long as they
point me to the document that has the information that I need.

> Hi,
>
> > When I look at the Repository, I only see three folders for most
> > books: Draft, Proofing, and Published. There is no Reviewed nor Feedback
> > folder. So, presently how are the folders used at the present time and
> > in what order?
> > How much trouble would it be to create the additional two folders
> > for each of the books in the Repository?
> > Instead of clicking "Submit for review" and moving the draft file
> > into the Proofing folder, is there another process that could be used?
> > Perhaps another folder called "Peer review" since it is being reviewed
> > by ones peers?
>
> The wiki is out of synch with the folder structure now on Alfresco.
>
> The Alfresco structure for each documentation is, as you say, Draft,
> Proofing, and Published. New work goes in Draft. When the work is
> done, you "Submit for review" and it gets transferred to Proofing.
> Someone reviews the doc in proofing. If it's publication-ready, you
> send it to Published. If not, you reject it and send it back to draft.
>
> I chose that because it was simple. It would be possible to create the
> additional two folders, but then the simple workflow designed and
> implemented would no longer work and would need re-implementing.
>
> At the time, I chose the current workflow because it was simple and I
> didn't really see the need for more complexity. Of course, that can be
> changed. But is it *really necessary*? What advantage would be
> procured? Those are the questions I asked myself at the time...
>
> --
> David Nelson
>
     I agree with you. I just did not know if we were going to change
the Alfresco structure of the documentation.

    And sometimes I don't edit what I have written. The last line above
should have been
"the Alfresco structure or the documentation."
   
Dan

Hi Dan,

I agree with you. I just did not know if we were going to change
the Alfresco structure of the documentation.

We can change either. But maybe more likely the documentation at this
time. However, if docs contributors decided another way of working was
better, we could adapt the working methods instead.

I want to think about it some and perhaps come up with a suggestion
for the documentation to match what we are now doing. So, if I do this,
should I post my suggestions to this mailing list or edit the
documentation by inserting them with my name?

IMHO, the most-constructive thing would be to post questions here for
public discussion, and then be ready to edit the documentation when a
conclusion had been arrived at.

I think you will find that I will have quite a few questions so
that I can understand what is going on. Once in a while I might need
someone to tell me to "read the manual" which is fine as long as they
point me to the document that has the information that I need.

No problem for questions, please do ask. Then, if they're likely to
come up regularly, it would be great if we could make sure they're
answered in the documentation.

Hi :slight_smile:
I think it's best to stick with the current system but obviously the documentation that describes it needs to be updated.

I tend to think that new people who have a lot of questions are likely to be the ones in the best position to really get that documentation right.  People who already understand the system might have forgotten 'obvious' questions.  I think maybe the first draft by techie people that do thoroughly understand the system might be best.

Changing the system just because soem people haven't yet understood the system seems a dumb idea.  It's kinda 2 steps backwards and then the backwards systems will need to grow and deal with the issues that the current system already deals with  At the same time the backwards system will have to worry about being backwards compatible as it tries to stumble forwards.  Eventually the backwards system would doubtless arrive where we already are but the journey would be painful.  Much better to simply document the current system and use it.

Just my 2cents.
Regards from
Tom :slight_smile: