ALFRESCO: New space for user docs

http://wiki.documentfoundation.org/cgi_img_auth.php/b/b9/ZINE_02_TRABALHOS.ods

Here is the file

Rogerio

I can setup the review/approve workflow for the spaces. Someone need to
decide the number of steps in the workflow and name each space/folder. I
also suggest configuring auto-versioning for all spaces so everyone can get
back older revisions.

Hi Samhan, :slight_smile:

I can setup the review/approve workflow for the spaces. Someone need to
decide the number of steps in the workflow and name each space/folder. I
also suggest configuring auto-versioning for all spaces so everyone can get
back older revisions.

It would be really terrific if you could do this. I feel that Ron
Faile is probably the best person to liaise with about this, because
Ron has the best feel for the workflow within the team right now.

Does anyone else have any thoughts on the subject?

David Nelson

My only thought at this point is that the workflow needs to allow for the
possibility of looping through several iterations of reviews and edits, or
just one iteration, depending on the individual document, similar to the
diagram on the /Documentation/Development wiki page.

Note: I know nothing about the way "rules" are set up for moving files from
one space to another, so what I just said may be a built in or default
feature that those familiar with "rules" might think is obvious and "of
course it's that way".

Hal

-- jdc

Hi Samphan, :slight_smile:

We'd really love you to do this work very much. As you know, you
already have the necessary permissions in the admin back-end. Let me
know if there's anything that has to be done at OS level.

Ron Faile has agreed to lead in working with you on establishing what
our workflow is and what we would ideally like it to be, because he's
the one among us that is closest to the workflow right now. We'll all
be pleased to chip in with advice, comments and help when needed.

We're very much looking forward to working with you, and thank you
very much for your kind offer. :wink:

David Nelson

Jeremy, what file is that supposed to be? It's not a glossary. Wrong
reference, perhaps?

Hal

Jeremy, what file is that supposed to be? It's not a glossary. Wrong
reference, perhaps?

Hal

I believe it was a spreadsheet which detailed and controlled Rogerio's
Broffice team workflow. A spreadsheet seemed to be a thought someone
else had on inclusion in the Alfresco set-up.

I would also add at this time a list which details the sort of task Ron
details in the following message.

Hi Shawn. One thing we need help with right now is creating quick
reference cards for each of the applications in LibreOffice. If you
would be willing to help with that, we should be able to get you
started.

-- jdc

OK, thanks. The context confused me, as it appeared to be in response to the
quote from my note about a glossary.

Hal

Oh yes, no. Sorry to confuse you. I was just gathering ideas people had
for David and Samphan re: the Alfresco setup and usage. :slight_smile:

-- jdc

Samphan,

Here is the workflow that I've come up with. It's basically what we are doing now on the wiki.

Folders: Drafts, Review, Proofing, Published

Step 1.

A user uploads a new file to the Drafts folder. Someone checks out the file from the Drafts folder to begin editing. The file stays in the Drafts folder and is marked that it is checked out and to show which user is working on it. If possible, prevent other users from editing the file while it is checked out.

Step 2.

The user downloads the file, makes changes and then uploads the file to Alfresco and checks the file back in. The user is then offered the option to either leave the file in the Drafts folder if the file needs further editing or if editing is complete, move the file to the next step in the process, the Review folder.

Step 3.

Another user goes to the Review folder and checks out the file, downloads it and reviews it. If the file was revised, it would be moved back to the Drafts folder and the document is checked back in. If it was ok and ready to proceed to proofing, the file is moved to the Proofing folder and the file is checked in.

Step 4.

A user goes to the Proofing folder, downloads the file and proofs it. If the file needs more work, it is moved back to the Drafts folder. If they agree it is ready for publishing, they go to the Proofing folder and mark that the file is ok. The file is marked as having been proofed once. Then a second user proofs the file and if they agree it is ready to be published, they mark that they have proofed the file and it is ok. Once the file has been proofed by two users, then it will be moved to the Published folder.

I agree about turning on auto-versioning. Let me know if you need anything else. Thanks.

Ron

I've just finished early implementation Ron's workflow and roughly tested.
Here's the procedure of the workflow in Alfresco (sorry for my English
-_-!):

Spaces: Drafts, Review, Proofing, Proofing2, Published

Only Alfresco users in the "Documenters" group are involved in this
workflow. Other users have read-only access to the spaces.

Step 1.

   1. A user go to the Drafts space, click "Add Content", choose file to
   upload, fill-in the document "Name", and in the "Type" field choose
   "Content".
   2. Someone checks out the file from the Drafts folder to begin editing.
      - To check-out a file, click on the "More Action" (triangle inside a
      circle button) and choose "Check Out".
      - Then choose the space for the working copy which should be in the
      user's home space.
   3. The checked-out files stays in the Drafts folder and is marked that it
   is checked-out by the "locked" icon. Hover at the icon to show which user is
   working on it.
      - Other users are prevented from editing the file while it is checked
      out.

Step 2.

   1. The user downloads the working copy, makes changes and then uploads
   the file to replace the working copy with new versions.
   2. When finish, click the "Check In" button of the working copy. The
   working copy will be removed and the original file will be editable again.
   3. The user is then offered the option to either
      - leave the file in the Drafts folder if the file needs further
      editing
      - or if editing is complete, move the file to the next step in the
      process, the Review space, by clicking at the "More Action" button and
      choose "Submit to Review"

Step 3.

   1. Another user goes to the Review folder and checks out the file,
   downloads it and reviews it.
   2. If the file was revised,
      - the user check-in the changes
      - then choose "Reject to Drafts" to move the file to Drafts space.
   3. If it was ok and ready to proceed to proofing
      - the user check-in the changes
      - then choose "Submit to Proofing" to move the file to Proofing space.

Step 4.

   1. A user goes to the Proofing space, downloads the file and proofs it.
   2. If the file needs more work, it is moved back to the Drafts space by
   choosing "Reject to Drafts".
   3. If the file is OK, it is moved to the Proofing2 by choosing "Submit to
   Proofing2". This is to mark that the file have been proofed once.
   4. Then a second user goes to the Proofing2 space, proofs the file.
   5. if the user agree it is ready to be published, s/he choose "Submit to
   Published" which move the file to Published space. That means the file has
   been proofed by two users

I've just finished early implementation Ron's workflow and roughly tested.
Here's the procedure of the workflow in Alfresco (sorry for my English
-_-!):

Spaces: Drafts, Review, Proofing, Proofing2, Published

Only Alfresco users in the "Documenters" group are involved in this
workflow. Other users have read-only access to the spaces.

Step 1.

  1. A user go to the Drafts space, click "Add Content", choose file to
  upload, fill-in the document "Name", and in the "Type" field choose
  "Content".
   2. Someone checks out the file from the Drafts folder to begin editing.
      - To check-out a file, click on the "More Action" (triangle inside a
     circle button) and choose "Check Out".
     - Then choose the space for the working copy which should be in the
     user's home space.
  3. The checked-out files stays in the Drafts folder and is marked that it
  is checked-out by the "locked" icon. Hover at the icon to show which user
is
  working on it.
     - Other users are prevented from editing the file while it is checked
     out.

This is done automatically by Afresco right?

Step 2.

  1. The user downloads the working copy, makes changes and then uploads
  the file to replace the working copy with new versions.

Again done by Afresco?

  2. When finish, click the "Check In" button of the working copy. The
  working copy will be removed and the original file will be editable
again.

Nice

   3. The user is then offered the option to either
     - leave the file in the Drafts folder if the file needs further
     editing
     - or if editing is complete, move the file to the next step in the
      process, the Review space, by clicking at the "More Action" button
and
     choose "Submit to Review"

Nice

Step 3.

  1. Another user goes to the Review folder and checks out the file,
   downloads it and reviews it.
  2. If the file was revised,
      - the user check-in the changes

We will have to MANUALLY check in the changes or will the revision feature
in LiO give us this?

     - then choose "Reject to Drafts" to move the file to Drafts space.
   3. If it was ok and ready to proceed to proofing
      - the user check-in the changes
     - then choose "Submit to Proofing" to move the file to Proofing space.

Step 4.

  1. A user goes to the Proofing space, downloads the file and proofs it.
  2. If the file needs more work, it is moved back to the Drafts space by
  choosing "Reject to Drafts".
  3. If the file is OK, it is moved to the Proofing2 by choosing "Submit to
  Proofing2". This is to mark that the file have been proofed once.
  4. Then a second user goes to the Proofing2 space, proofs the file.
  5. if the user agree it is ready to be published, s/he choose "Submit to
  Published" which move the file to Published space. That means the file
has
   been proofed by two users

Nice

- Overall a very robust publishing system... my only question: IF reviewer
vanishes (has happened in the past) can someone get the copy of the file? in
the step it was left behind (I assume yes) ?

Rogerio

> I've just finished early implementation Ron's workflow and roughly
tested.
> Here's the procedure of the workflow in Alfresco (sorry for my English
> -_-!):
> Spaces: Drafts, Review, Proofing, Proofing2, Published
> Only Alfresco users in the "Documenters" group are involved in this
> workflow. Other users have read-only access to the spaces.
> Step 1.
> 1. A user go to the Drafts space, click "Add Content", choose file to
> upload, fill-in the document "Name", and in the "Type" field choose
> "Content".
> 2. Someone checks out the file from the Drafts folder to begin
editing.
> - To check-out a file, click on the "More Action" (triangle inside
a
> circle button) and choose "Check Out".
> - Then choose the space for the working copy which should be in the
> user's home space.
> 3. The checked-out files stays in the Drafts folder and is marked that
it
> is checked-out by the "locked" icon. Hover at the icon to show which
user is
> working on it.
> - Other users are prevented from editing the file while it is
checked out.
This is done automatically by Afresco right?

Yes.

Step 2.
> 1. The user downloads the working copy, makes changes and then uploads
> the file to replace the working copy with new versions.
Again done by Afresco?

The user just choose "Update" and select the file to upload.

> 2. When finish, click the "Check In" button of the working copy. The
> working copy will be removed and the original file will be editable
> again.
Nice
> 3. The user is then offered the option to either
> - leave the file in the Drafts folder if the file needs further
> editing
> - or if editing is complete, move the file to the next step in the
> process, the Review space, by clicking at the "More Action" button
> and
> choose "Submit to Review"
Nice
> Step 3.
> 1. Another user goes to the Review folder and checks out the file,
> downloads it and reviews it.
> 2. If the file was revised,
> - the user check-in the changes
We will have to MANUALLY check in the changes or will the revision feature
in LiO give us this?

Yes. The user must manually check-in/upload the revised file if s/he want to
make change.
If s/he just want to "read" the document then s/he can just download the
file w/o checking out.
The versioning in Alfresco is to call a new version after each update. If
you access Alfresco thru CIFS, update is merely saving the file. For
web-based Alfresco Explorer, update is an upload.

> - then choose "Reject to Drafts" to move the file to Drafts space.
> 3. If it was ok and ready to proceed to proofing
> - the user check-in the changes
> - then choose "Submit to Proofing" to move the file to Proofing
space.
> Step 4
> 1. A user goes to the Proofing space, downloads the file and proofs it.
> 2. If the file needs more work, it is moved back to the Drafts space by
> choosing "Reject to Drafts".
> 3. If the file is OK, it is moved to the Proofing2 by choosing "Submit
to
> Proofing2". This is to mark that the file have been proofed once.
> 4. Then a second user goes to the Proofing2 space, proofs the file.
> 5. if the user agree it is ready to be published, s/he choose "Submit
to
> Published" which move the file to Published space. That means the file
> has been proofed by two users
Nice
- Overall a very robust publishing system... my only question: IF reviewer
vanishes (has happened in the past) can someone get the copy of the file?
in
the step it was left behind (I assume yes) ?

An admin can undo a check-out of everyone and undelete every files.

Hi, :slight_smile:

@Samphan:

a) Jeremy Cartwright wrote back to the list today about something he
has been experimenting with (see [1]). Can you tell us what you think
about this? I'm only worried that you don't seem to be in contact with
each other, and so there may be redundancies or interferences between
what you are both doing... Can you please advise Jeremy about his
work, and advise us how it relates to your own development work?

b) Could you tell us what the situation is regarding the
auto-versioning with the workflow you'v, designed?

@Jeremy: Could you give us your reactions, please, Jeremy?

@Ron: Could we hear from you, too, please, Ron?

TIA, guys. :wink:

David Nelson

Hi, :slight_smile:

Samphan, with regard to the message I just posted here in this thread,
could you maybe take a look at Jeremy's post in this thread below?

http://nabble.documentfoundation.org/alfresco-links-tp2241517p2244343.html

Thanks. :wink:

David Nelson

Sorry, I've miss reading the thread :P.
Jeremy's work on the Alfresco spaces is virtually the same as I do. The
differences are just the layout, number of steps in the workflow and
wording.

There's a redundancy because of the rule I and Jeremy used to enable
versioning which is easy to fix.

The "only" other thing that I've done is add the group "Documenters" as
"Collaborator" role to the space "LibreOffice Documentation". This allows
anyone in the group to add/edit every files in the space/subspaces but only
allow the owner/admin to delete a file. I guess this is the right thing to
do?

Hi, :slight_smile:

Sorry, I've miss reading the thread :P.
Jeremy's work on the Alfresco spaces is virtually the same as I do. The
differences are just the layout, number of steps in the workflow and
wording.

There's a redundancy because of the rule I and Jeremy used to enable
versioning which is easy to fix.

OK, please see below.

The "only" other thing that I've done is add the group "Documenters" as
"Collaborator" role to the space "LibreOffice Documentation". This allows
anyone in the group to add/edit every files in the space/subspaces but only
allow the owner/admin to delete a file. I guess this is the right thing to
do?

Yes, for sure.

What is the situation regarding auto-versioning? This is a feature
we'd be *very* keen to have.

@Samphan, @Jeremy:

So what's the solution? You work together? You integrate what you've
done? What shall we do here?

Whatever you both decide, I would definitely like Samphan to carry on
working with us as maintainer and developer. I'm hoping that Samphan
will do theming work on the site, if it is decided to integrate this
site into the TDF Web resources (this is a subject I'll be
following-up on with him very soon).

@Ron: could you maybe give us your take on this, too?

David Nelson

my 2cents

the work is very similar , but:

1 Jeremy¬īs Versioning rules seems a better lock-down on our needs
2 Samphan¬īs use of "group" policies will facilitate things for the
admins/recruiters.

Rogerio

Jeremy's work on the Alfresco spaces is virtually the same as I do. The
differences are just the layout, number of steps in the workflow and
wording.

Yes, they are very similar. I seem to prefer Samphan's work as it makes it easier to follow. I like his naming of the folders too. TestFin was just confusing to me.

The "only" other thing that I've done is add the group "Documenters" as"Collaborator" role to the space "LibreOffice Documentation". This allowsanyone in the group to add/edit every files in the space/subspaces but onlyallow the owner/admin to delete a file. I guess this is the right thing to do?

Yes I think this is a good idea and fits what we need it to do.

@Samphan, @Jeremy:

So what's the solution? You work together? You integrate what you've
done? What shall we do here?

I would also like to see the two works integrated and to have more collaboration in the effort. Thanks to both of you.

Whatever you both decide, I would definitely like Samphan to carry on
working with us as maintainer and developer. I'm hoping that Samphan
will do theming work on the site, if it is decided to integrate this
site into the TDF Web resources (this is a subject I'll be
following-up on with him very soon).

Please do Samphan.

@Ron: could you maybe give us your take on this, too?

David Nelson

Instead of rushing to completion and implementation of Alfresco, I would like to see more time given to the process and let others who have not tried it yet or the new workflow to get in there and see what it's like.
Are we going to have a working version of Samphan's work on the site to give it a test as well?

Ron