RE: [office-formula] Handling of JIRA issues

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

It is clear to me that I can find defects without knowing how they should be
resolved or even might be resolved.  I might notice that something is
underspecified, inconsistent, or that there is a contradiction with another
provision without knowing what the correct resolution might be and what the
original intention was when the provision was introduced.

For example, I have no idea how to specify what is essential about a
manifest.rdf document in an ODF 1.2 package, yet I can easily determine that
there is not enough information for the implementer of a producer to be able
to know the answer from the specification itself, which means that consumers
won't know what to expect or count on either.  Finally, the condition that
editing of a document should preserve the RDF metadata is ridiculous, but
providing a sharper statement is very difficult.  (I understand it is only a
recommendation in the JTC1 normative-language sense, but it is a very
peculiar recommendation in this case.)  

The same thing happens with regard to, say, OpenFormula section 4.8 on
Reference syntax.  There is not enough information to know how a cuboid is
determined in all of the variations, and what the additional requirements
are for a cuboid to be determined.  There's more.  I could propose by
guessing, like I did for the allowed text of passwords in order to be
precise with regard to table:protection-key and
table:protection-key-digest-algorithm, but it would be irresponsible for me
to claim that this is a correct or even agreed resolution.

In some case, I might be able to say what sort of action needs to be taken,
but I would not know what are the correct specifics.

The fact that someone doesn't raise their hand to fix it does not mean, to
me, that a recognized, significant defect should receive a free pass and be
"shipped."  We might need to make a policy decision, declare the feature
implementation-dependent, or something like that.  I guess I could propose
such resolutions.  Does that seem satisfactory, if I or anyone else were to
see an unowned issue about a substantive defect no one takes on?

 - Dennis

-----Original Message-----
From: Michael.Brauer@Sun.COM [mailto:Michael.Brauer@Sun.COM] 
Sent: Tuesday, April 20, 2010 03:57
To: dennis.hamilton@acm.org
Cc: 'Eike Rathke'; 'OASIS ODFF SC'
Subject: Re: [office-formula] Handling of JIRA issues

[ ... ]

I don't think that will happen. If something is really clearly a defect, 
then there should be some understanding how to resolve the defect. 
That's because some knowledge what would be correct is required to judge 
that something is a defect. I further strongly believe we are all 
interested in a good specification. If a particular improvement is 
considered to be important not only by the submitter of the issue, then 
there should be someone who cares.

> 
> I suppose one resolution would be to remove whatever feature has the
> unresolved defect, but that might not always be a very welcome solution.
I
> guess we need to see what actually comes up before we decide to tie our
> hands in advance.

We other option is to keep a particular detail implementation dependent. 
That's not a perfect solution, but I think on many cases better than 
dropping a feature.

Michael
> 
>  - Dennis
> 
> -----Original Message-----
> From: Eike Rathke [mailto:erack@sun.com] 
> Sent: Monday, April 19, 2010 08:16
> To: OASIS ODFF SC
> Subject: [office-formula] Handling of JIRA issues
> 
> Hi,
> 
> Since we're nearing CD3 and following that the hot phase of a public
> review, I'd like to propose a handling of JIRA issues until CD3 and
> review:
> 
> New and unassigned issues may not have a ODF 1.2 (CD3 or final) target
> set unless
> 
> a) Someone commits himself to resolve the issue for a specific target.
> 
> b) The TC/SC agrees on a target for the issue AND finds someone for a).
> 
> Following that, of course it is valid to submit an issue, regard it
> important enough for CD3, resolve it and target it to CD3.
> 
> However, it is invalid to submit new issues and target them to CD3 if no
> one committed on resolving the issue.
> 
> Otherwise having the target doesn't make sense.
> Opinions?
> 
>   Eike
> 


-- 
Michael Brauer, Technical Architect Software Engineering
StarOffice/OpenOffice.org
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500
http://blogs.sun.com/GullFOSS

Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
	   D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Jürgen Kunz



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php