Re: [office] Change tracking requirements comments

[Svante Schubert <svante.schubert@gmail.com>]

Thanks for pushing this further on the list, Rob.

I would love to map every requirement to a scenario (if the comment/explanation is not already the scenario). Some might differentiate between end user scenarios and application vendor scenarios (which would finally map to a user scenario), but this is not important IMHO. But we might think about some classification of scenarios, like marking interoperability, metadata, efficiency scenarios. Grouping might have the nice side effect, we might group similar scenarios together, finding easier duplicates.

More important, when reading we should prioritize the requirements into three groups: 1, 2 and 3. Where 1 is the most urgent group with certain scope of our next release and 2 like a maybe for next release and 3 with a worthwhile, but follow up requirement.

The latest requirement list counts 38 columns.
Having a closer look 33-38 are draft report questions, which are worth to be answered and should remain for now, but should be mapped to scenarios.

I started to copy paste everything from the wiki into an ODF spreadsheet and added priorities as described above. I will upload it, so anyone, could adapt the document according to their own priorities as note for the upcoming call.
Again the spreadsheet is not meant as data duplication to the wiki, which is our main data store, but as a simple working utility. (see http://www.oasis-open.org/committees/document.php?document_id=45468&wg_abbrev=office)

Svante

On 17.03.2012 20:31, robert_weir@us.ibm.com wrote:

Hopefully you are able to all find some time before Monday's call to read through the draft requirements for change tracking as posted on the wiki:

http://wiki.oasis-open.org/office/Change%20Tracking%20Meta%20Requirements

We can streamline the call a bit if you raise any priority issues or concerns you have,especially for the items after 9, which is as far as we got last week.

Some quick comments from me:

10, on ordering.  A user most typically expects to view the tracked changes in order of the document's presentation, i.e., "visual document order". Do any apps have a UI for doing this in chronological order of the changes?  Interesting idea, but I don't think that I would optimize for that scenario.

12, 13, 15, 20, 21 and 27 seem to all be variations on a common concern:  ODF is a standard for a document format.  It is not a standard for a word processor or other editor, beyond some formatting and layout guidance.  In particular we have not defined the permissible editing operations for an editor.  I think this is the key question.

22, reuse of existing version control mechanisms -- I think this was based on an observation that an application could simply embedded something like git and have a very fully-featured way of tracking versions, merging changes from different users, etc.  It is an interesting approach, for an application to take.  But we need to ensure that as a standard ODF remains application neutral.  If there were an actual standard for the storage of version control, info, then that would be more interesting.

-Rob