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, 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
