wsbpel-reqts message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [wsbpel-reqts] splitting issues
- From: Diane Jordan <drj@us.ibm.com>
- To: "bpel rqmts" <wsbpel-reqts@lists.oasis-open.org>
- Date: Fri, 1 Oct 2004 09:26:33 -0400
Peter,
Thanks - I really appreciate your help!
A comment on your remark -
"It would be possible to
have daughter issues that overlapped (when there are different proposals
for aspects of the parent), though one hopes the tc would not pass an inconsistent
set."
I don't think we should use subissues as a way to deal with alternate proposals
- just for splitting the problem problem statement in to more manageable
chunks.
Should we consider whether the remaining
pieces should be also identified when a subissue is opened. This
would mean there would always be at least two subissues. For example,
require that when 116.1 is opened, we also open 116.2 to cover the northern
hemisphere, so its clear what work remains. I'm not sure whether
this would be helpful or more confusing.
Regards, Diane
IBM Emerging Internet Software Standards
drj@us.ibm.com
(919)254-7221 or 8-444-7221, Mobile: 919-624-5123, Fax 845-491-5709
"Furniss, Peter"
<Peter.Furniss@choreology.com>
09/30/2004 06:09 PM
|
To
| Diane Jordan/Raleigh/IBM@IBMUS,
"bpel rqmts" <wsbpel-reqts@lists.oasis-open.org>
|
cc
|
|
Subject
| RE: [wsbpel-reqts] splitting
issues |
|
Sounds good in general, to keep
everything clear, as you suggest.
In investigating how feasible,
it was easier to do it - won't show up until acted on.
It's easier to make the subissues
103.1 rather than 103.a, as the sorting works out easily ( I hope
we don't go beyond 9 subissues)
I've made it so I can create a
subissue from an existing one, then add whatever entries are needed. The
intent was that a proposed partial resolution would cause a split, leaving
the parent unchanged (and typically open). Presumably the subissue description
would only need to define the scope of the subissue, rather than having
to go through all the details (though it could if appropriate)
We could also (as a tc) just decide
to split an issue, when there wasn't a current proposal
I guess the parent issue wouldn't
close until all its daughters closed - even though a daughter might cover
90% of the problem area.
It would be possible to have daughter
issues that overlapped (when there are different proposals for aspects
of the parent), though one hopes the tc would not pass an inconsistent
set.
If a daughter is split, a sister
is created, not a grand-daughter of the original (thus avoiding issue numbers
like 103.2.1)
It may take a few iterations to
get things automated - which would require a new pattern in the subject
line for the proposed partial resolution. I currently allow some flexibility
there (Issue 123 - Proposed resolution and Issue 123 - Proposal to ...)
both work. Perhaps "Issue 123 - Proposed partial resolution"
would cause the proposal to be applied to a newly split 123.n.
At first, I can work out the splitter
commands by hand though.
As an example, I've split the
april fool issue 116 (I'll take this out again later)
Peter
-----Original Message-----
From: Diane Jordan [mailto:drj@us.ibm.com]
Sent: 29 September 2004 18:10
To: bpel rqmts
Subject: [wsbpel-reqts] splitting issues
It seems as we're getting into some complex issues, people are interested
in offering partial resolutions to make progress without closing the entire
original issue. I think this is good. However, how it brings
up questions about how we should handle the issues. We've opened
new related issues in some cases. This doesn't necessarily reflect
the close tie between parts of an issue. In others we just left
the issue open (or closed and reopened), and had some resulting confusion
about whehter there was work left to be done. I'd also like to make
sure we have a sense of how many sub issues are being split off.
I've been thinking about the ability to identify parts of issues with letters/dot
numbers - eg, issue 103 a or 103.1 etc. and asking those who
provide a partial resolution to also provide the sub issue descriptions
when they propose the partial solution.
Peter, would this even be possible in our list?
If so, what does this subgroup think? We'll have our regular call
next week and can discuss then, or let us know by email.
Regards, Diane
IBM Emerging Internet Software Standards
drj@us.ibm.com
(919)254-7221 or 8-444-7221, Mobile: 919-624-5123, Fax 845-491-5709
Choreology Anti virus scan completed
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]