RE: [office] RE: [odf-adoption] Interest in ISO version of ODF 1.1?

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

Considering how much ODF 1.1 matches the content of IS 26300:2005, the
translation burden should be much less than what the eventual burden for 1.2
will be.  

I understand that it is still more work, and I sympathize.  Are you really
still specifying ODF 1.0 (IS 26300) in procurement and standardization
policies in Brazil?  

A calibration on the actual amount of difference to be dealt with should be
useful in determining the problem.  Reducing the need for translation might
also be an important factor in how the move to 1.1 is done at the ISO level.
Rob mentioned that this might be done as an amendment to IS 26300:2005.
Perhaps the amendment approach can be used to mitigate the amount of
translation involved, assuming the amendment can be translated as a
separate, smaller document.

With regard to timing, you said 

    "I think that this should be a good idea a few years ago, 
     but with ODF 1.2 almost ready, this decision would impose
     us an unnecessary effort." 

I don't think ODF 1.2 is almost ready as an ISO Standard, and I haven't done
the math on the PAS submission time sequence, but it seems to me that we
might be as much as two years away from appearance of an IS for ODF 1.2.

My other concern is that we really don't know big the gap is between almost
ready and ready at the OASIS level, we only know the least it can possibly
be.  

My past awful experiences under those conditions says that, if one can
accomplish it as a bounded effort, maintenance work (in this case, alignment
of OASIS and JTC1 at ODF 1.1) is important insurance against the prospect of
future-release (i.e., 1.2) slippage.  Since we are using best-case estimates
for ODF 1.2 readiness, it is easy to make book on their being some slippage,
perhaps even a painful amount.

A risk-management-based approach would, I think, suggest that we look at PAS
submission of 1.1 if the effort can be confined as a way to mitigate our
problems with synchronized maintenance and also any variation that happens
before 1.2 achieves ISO/IEC IS status.

 - Dennis

 - - - - - - - -

More thinking out loud:

Every time someone talks about ODF 1.2 being almost ready, I cringe.  It is
probably an automatic thing, based on my past experience, but it just fills
me with dread based on some simple and frequently-repeated experiences over
a long career.  My experience is so consistent that I can only think of two
exceptions.  

1. Every time I suspended maintenance on an existing package because a
revision was coming real-soon-now, I came to regret it.  The revision was
much later or was even cancelled.  It was never available real-soon-now.

2. I even withheld source code on a package once (back when giving away
source from a computer manufacturer was easier and software patents and
copyright were not allowed), because I didn't want to see a fork or deal
with feature feedback when a rewrite was coming real-soon-now.  By the time
the rewrite was available, the customer who wanted to work on the code and
add some value had moved on to other things.

So, my personal record for not doing X because event Y will have made it
wasted effort is not very good.

Apart from my own incompetence, why is that?

I think it is about failing to address risk management as a crucial element
of software development.  I see three elements of that in the ways I have
blundered in the past:

A. Thinking that the speculative future alternative is less difficult and
always easier than the painful present and known experiences, leading to use
of best-case, optimistic estimates of a chain of events that can almost
never be achieved.  (I think this is the common cold of software development
and IT management, but knowing that does not prevent me from getting the
sniffles from time to time.)

B. Not having an actionable, reviewable plan and grasp of all the tasks that
it actually takes to get to the speculative future - having no roadmap for
making the achievement tangible and also measuring progress, being agile,
etc.

C. (A contributor to B), Not preserving a historical record from the march
to the painful present as a resource and calibration on any future effort,
along with silly ideas about learning-curve (e.g., it took X before so the
next one should take X/2, even though the level of change and new required
learning is significant).

There are a number of death-spiral symptoms that are indicators of an
impending software-project collision with reality, and I wonder if standards
development is sufficiently like software development that we should be
watchful for those too.



-----Original Message-----
From: Jomar Silva [mailto:jomar.silva@br.odfalliance.org] 
http://lists.oasis-open.org/archives/office/200902/msg00074.html
Sent: Friday, February 06, 2009 08:50
Cc: office@lists.oasis-open.org
Subject: Re: [office] RE: [odf-adoption] Interest in ISO version of ODF 1.1?

As the responsible of working group that produced the Brazilian 
Portuguese version of ODF (NBR ISO/IEC 26.300), I think that this should 
be a good idea a few years ago, but with ODF 1.2 almost ready, this 
decision would impose us an unnecessary effort.

On the last time, it took us almost a year to translate and revise the 
ODF standard and it costs a lot here. I would wait a few more months and 
do the necessary effort to work on ODF 1.2 (I think that the same 
scenario would apply to all countries where the translation to local 
language is mandatory).

So for me, at this moment, this is priority 1 (to respect Rob's scale, 
because on my own this should be a -10).

Best,

Jomar

Dennis E. Hamilton wrote:

> I'm certainly in favor of this enough to dig deeper and find out what the
> scope of the effort would be and how many changes have to be dealt with.
> That strikes me as an ideal way to synchronize with JTC1.
>
>  - Dennis 
>
[ ... ]