Documents lifecycle ("stages")

Hi Babynus!

I want to congratulate you on a new version, with nice new features and (IMHO) more importantly, swift bugfixing. You introduced big upgrades as "multiple changing of elements" (something that, in itself, could have "deserved" a major version) and resolved quickly any bug that came out from that. Congratulations!

Now, to the point

I've been wondering (and wandering, too, probably ) about how to deal with document approval process for some time now. I've proposed several new features regarding it, most of them (thank you!) already tracked within Project'OrRIA's roadmap.

So, a few days ago (quite some, actually, but it's been a few busy weeks at work), it came to me that I was missing a point here (probably an important one):

Documents, same way as products do, have a certain "lifecycle". Trough their "existence", they must evolve through certain "steps" or "stages" according to their "maturity level". At least, that is so in industry and construction, where docs are first useful to discuss a project, then (after proper refinement) they are documented instructions for erection, and finally, they reach their last "goal" as final (closed) documentation describing what's been done, and the final state of the construction (e.g.: the plant, or the multiple-storey building) kept as reference for, e.g., following building extensions.

So, a typical lifecycle for a document, would go over (e.g.) these "stages":
I - Preliminary
II - For discussion
III- For quotation
IV - For construction / for production
V - As built / as manufactured
VI - For (future) reference [CLOSED]

Of course, depending on the importance and size of the project, perhaps not every document would need to go over all these steps.

Basically, you would:
1- Create minor versions while in internal review/approval process.
E.g.: a1, a2, a3...

2- Once the document gets approved by the responsible of the project, the major version gets published to the client. It also becomes "a reference" of that version.
E.g.: A (is reference)

3- Only then is the client able to see that doc, and review it. And, here comes the thing:

- If he/she don't validate it -> it remains at the same stage. New uploads would change version to next index, and go back to (1).
E.g.: b1, b2, b3...

- If he/she does validates it -> it advances to the next stage. New uploads would change version to next index, and go back to (1). (*)(**)
E.g.: from stage III to stage IV -> 0.1, 0.2 (***)
E.g.: from stage II to stage III -> b1, b2

(*) Of course, once it gets to stage VI: "For (future) reference", the review workflow is over.

(**) Perhaps it wouldn't be necessary for every doc to go through all those stages mandatorily. It might be nice to provide the customer, in the "validation window", with a drop-down list where he/she can choose the next stage the document is advancing to (defaulting to the one previously defined by portal administrator).
E.g.: he/she might consider a "Stage I" doc ("Preliminary") good enough so as to promote it to "Stage IV" ("For production"), bypassing stages II and III.

(***) Sometimes a change of stage also (usually) implies a change in the revision index format. It's common use that revisions in stages I, II and III are represented by letter indexes (A, B, C...), while from stage IV on they're represented by "number" indexes (0, 1, 2...)


So, the question: is there (already) a way to manage this process in Project'OrRIA?

I believe there isn't right now, but it's not very far. Some aspects of this behaviour are already there, some is already on the roadmap, and I believe only the stages thing would be missing. But not by far: there's already "Versions" elements for projects/products. I imagine it would be possible to adapt these to be able to define documents "stages", and, with further fine-tuning, be able to manage this process I've just described.

Besides, "Versions" are defined by portal admin, so it would be configurable if/which stages the company is to use.

Personally, I believe there should be a portal default stages config, that can be overriden project-wise by the project manager. Because it may be the case that companies set a high standard, with a more complex review process, for big, long projects, but need to simplify it for small, simple projects that need to get defined more quickly.

I'd like to propose this process as an evolution for Project'Or RIA, because I believe it would "take it to the next level" regarding documents management/workflow. Somehow it includes and complements other (already asked-for) features that are already there, or on their way.

What do you think, Babynus?

babynus wrote: 1) using document management, managing "stages" as document status

I think, from a user's perspective, this is the most desirable approach. Only that in order to organize our work and resources we cannot lose "work" status information.
Besides, these are two different "properties" of the doc, which coexist "in parallel": within a certain stage doc's status changes respecting the pre-configured workflow. But once the current stage gets validated, it should restart (or go back a few steps) in that workflow, and, at the same time, should move forward one stage.[1]
So, they'd be two different properties:
- Stage (more of the "maturity level" of the doc itself, is a property that belongs inside the document)
- Status (more of a "virtual" property, regarding the actual work that's been done on the current version of the doc, belongs to meta-data, useful for project-management and organization only)
[1] As I said before, it'd probably be nice to have the chance (for example, through a drop-down list) to bypass stage(s) while validating a certain doc's stage.

2) using document management, managing "stages" as major versions (you could then use manual version management to define your stages as version label)

This could do as a kind of "handcrafted" workaround. It's not an ideal solution, mainly because it's more difficult to set company-wide standards regarding stages labels, and their order. And, because you'd have to actually do all the properties-filling work yourself
The idea of all this workflow thing is that the software gets to "decide" who's turn it is to act on the document, and get's to register (all by itself) all changes and different "statuses". If it becomes extra work, then it's not so useful anymore, but more of a burden.

3) using products (a document can be considered as a product or sub-product of main product in your case) management avec product versions

You mean not using "document" elements at all, but replacing them with "products" (or sub-products)? I think that'd be quite unintuitive. It might actually work, perhaps, but I don't think it's the way it should work.

---

A nice improvement, I believe, would be to define a new element "Stages" (so that every portal admin can define the labels he/she likes most) that can interact with Statuses. Define predecessor/successor among them, and on which status is a change of Stage triggered.

Could this be possible?

Perhaps this doesn't work with (or doesn't make sense at all with) other versioning systems such as "chronological". So all this should be limited to "evolutive". Or, even better, make another versioning scheme, since maybe evolution type is more "software-development" oriented and doesn't need this Stages thing.

babynus wrote: Ticket #1170 recorded.

Great!

and as soon as in v3.x?? \o/ \o/

By the time 4.0 is out, my life (and many other's, for sure) at the office will have become a lot easier!

Thanks!

One thing I had forgotten: this "stage" information should be visible in the upcoming "Document exchange list" (Ticket #1123).
And, as an even-nicer-to-have improvement, one should be able to filter (for that report) documents based on such status.
Cheers!