Re: [office] Tracking issues

[Michael Brauer <michael.brauer@oracle.com>]

Hi,

On 19.01.2011 02:46, robert_weir@us.ibm.com wrote:

OF9DF1E3E1.FF901FF4-ON8525781D.0005CA77-8525781D.00095C03@lotus.com" type="cite">

Patrick Durusau <patrick@durusau.net> wrote on 01/18/2011 07:00:44 PM:

  

Just a couple of thoughts to follow up on the discussion about tracking
issues for ODF-Next.

I think it was Oliver who suggested that we could use due dates and
assignments to track the processing of issues in JIRA.

Since assignee is pretty much all over the place, for various reasons, I
would suggest the following:

1) As of our next TC call, let's agree that we blank the assignee field
for all ODF-Next issues.

    

This is easy to do.
  

+1

OF9DF1E3E1.FF901FF4-ON8525781D.0005CA77-8525781D.00095C03@lotus.com" type="cite">

2) Let us further agree that when issues are "approved" for inclusion,
at that point, an assignee is given the issue and entered in JIRA, along
with a due date.

    

OK.
  

+1

OF9DF1E3E1.FF901FF4-ON8525781D.0005CA77-8525781D.00095C03@lotus.com" type="cite">

If we really want to track things, I would suggest putting the TC
meeting date of the assignment in the JIRA entry for that issue.

    

We are not able to modify the creation date for the issue.  But we could 
add a comment saying when a proposal was accepted, and that comment would 
be automatically dated.
 
  

3) An issue is not "resolved" until the TC approves the solution
proffered by the assignee. 

    

But by "approval" I'd suggest that this could take different forms 
depending on how far advanced we are in the process.  For example, 
initially we might want to accept all proposals unless there is an 
objection.  That might work for CSD01.  But we might change the bias so by 
the time we have our final CSD no changes are accepted unless discussed 
and approved by the TC.  That encourages stability as the work progresses. 
  

+1

OF9DF1E3E1.FF901FF4-ON8525781D.0005CA77-8525781D.00095C03@lotus.com" type="cite">

Thinking that Rob's opportunity to object to features he doesn't like
occurs at #2, which is prior to a lot of effort being spent. 

    

I can object at any point, as can any other TC member.  But I think we'd 
all want to hear concerns earlier rather than later, so anything we can do 
to encourage that helps us all.
  

+1

OF9DF1E3E1.FF901FF4-ON8525781D.0005CA77-8525781D.00095C03@lotus.com" type="cite">

BTW, TC approval for #3 should be on the agenda and notice given that it
is about to be voted on by the TC. 

    

As above, it might be treated as an exception process initially.  It 
should not be necessary to explicitly vote on every proposal from the 
start.  I think this will depend on the number of proposals we're dealing 
with.
  

Right. I think what is important is to know for TC members is that it may become more difficult to get something into ODF if we are getting closer to an OASIS standard. It is therefore worth to care about the proposal one is interest in rather early than late.

OF9DF1E3E1.FF901FF4-ON8525781D.0005CA77-8525781D.00095C03@lotus.com" type="cite">

What does the foregoing *not* capture or that could be captured better
by some other mechanism? 

Apologies for the early focus on process but I would like to get those
issues out of the way so that we will have a clear status on issues and
a process for dealing with them. 

    

How long do TC members need before having a proposal ready for review 
until they are able to approve or object to it?  Is one week sufficient? I 
think the Apache style voting we did in JIRA, with +1/-1, etc., worked 
well.  We need something that scales, and having items come up for 
discussion/resolution in TC meetings does not scale.  Heck, it barely 
scaled in the Formula SC.  So I think we need a method of processing 
proposals that encourages development of consensus via JIRA in almost all 
cases.  It should be very rare that we need to have a formal 
discussion/vote on a call. 
  

I think the process we used in the TC for the work on comments did work sufficient well. It included the voting option you mention above, but also the option to set issues on a "needs discussion" status.

A difficulty when working mostly with JIRA could be that it is difficult to notice changes to the issues one is interested in. JIAR sometimes does not send out notifications at all, and even reading through the notifications that are send out needs a lot of time.

But we may solve this issues by opening issues only when work on an issue starts, and by having frequent working drafts that include resolved issues. When an issue is applied, we may set it to "applied" immediately, as we did in the past.

We when have the following options to find issues:

Status "New" - no one is working on the issue. No need to review it.
Status "Open" - Someone is working on the issue. If I like to participate in its resolution, then I should track the issue.
Status "Resolved" - Resolved issue. All TC members should review these issues frequently and cast their votes.
Status "Applied" - The issue is available in a working draft.

We may further agree that we use change tracking to mark the changes between working drafts (not CDs). This would provide the option to review changes to the specification without having to care about JIRA. But ideally we receive feedback for issues before they are applied. So, I still would encourage TC members to use JIRA.

Michael

OF9DF1E3E1.FF901FF4-ON8525781D.0005CA77-8525781D.00095C03@lotus.com" type="cite">

-Rob


 
  

Particularly if we are talking about a new draft every 6 months. (which
I think is a very good idea)

Hope everyone is having a great day!

Patrick
-- 
Patrick Durusau
patrick@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau
Newcomb Number: 1


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

    

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

  

--

Michael Brauer | Oracle Office Development
Phone: +49 40 23646 500 | |
Oracle Office Global Business Unit

ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Rijnzathe 6, 3454PV De Meern, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven

Oracle is committed to developing practices and products that help protect the environment