Michael –
Thanks for the reply.
One problem I see with the workflow is that it assumes issues are independent.
However, larger issues often arise from combining a number of related issues,
developing a solution, and refactoring the tickets into workable units.
Perhaps we should have a way of closing an issue indicating that it has been
merged into or superseded by another issue. I’m not sure the extent to which
Burke’s proposal addresses this.
Also, you indicate that in the first step of the 3-step process, the issue is
reviewed for sufficiency. I think it ought to include a decision as to whether
this issue is large enough to require a more formal design stage. This first
step is also where a decision not to do a particular issue is made; this should
probably be reviewed to prevent arbitrariness.
Saludos, Roger
From: [email protected] [mailto:[email protected]] On Behalf Of Michael Downey
Sent: Friday, September 16, 2011 1:13 PM
To: [email protected]
Subject: Re: [OPENMRS-DEV] Design discussions
Hi Roger et al,
On Friday, September 16, 2011 at 10:37 AM, Friedman, Roger (CDC/CGH/DGHA) (CTR)
wrote:
Is there some way we could improve this process for issues that require design?
For example, by saying that each Jira ticket must be either a sub-issue of
another Jira ticket or of a Wiki page? The master Wiki page and Jira ticket
would cross-reference all related Wiki pages and Jira tickets.
If my understanding of history is correct, our approach came from Karl Fogel's
book, "Producing Open Source Software", an often-cited resource used by many
projects. In the section "No Conversations in the Bug Tracker", Fogel points
out [0] the important issues you raised again in your mail. However, I point
out something in that section that we often overlook:
Always link to the mailing list thread from the issue, when you choose to post
to the mailing list. It's still important for someone following the issue to be
able to reach the discussion, even if the issue itself isn't the forum of
discussion. The person who starts the thread may find this laborious, but open
source is fundamentally a writer-responsible culture: it's much more important
to make things easy for the tens or hundreds of people who may read the bug
than for the three or five people writing about it.
It's fine to take important conclusions or summaries from the list discussion
and paste them into the issue, if that will make things convenient for readers.
A common idiom is to start a list discussion, put a link to the thread in the
issue, and then when the discussion finishes, paste the final summary into the
issue (along with a link to the message containing that summary), so someone
browsing the issue can easily see what conclusion was reached without having to
click to somewhere else. Note that the usual "two masters" data duplication
problem does not exist here, because both archives and issue comments are
usually static, unchangeable data anyway.
These are good points and I think we should work harder to ensure that issues
are updated with links to the discussions, wiki pages, etc., that come out of
the design process.
Do we need to have separate design-phase and build-phase tickets? We also need
a way to move back to design after tickets have been worked -- this is the case
with the current discussion of object attributes, global properties and complex
objects, which have turned out to be similar enough to make harmonization
worthwhile. And it would be good if we could equal the convenience of watching
just one ticket as opposed to multiple tickets and wiki pages.
I feel, generally speaking, that splitting an issue for design is not necessary
since we have a design state. Issues can also reach that design phase after
work has begun, if necessary. That said, in some cases it may be necessary to
have multiple issues. JIRA can link issues with different relationships for
this reason and should that scenario become necessary, it's important to keep
them linked.
Where is the state diagram for the Jira process?
Yes, it's posted on the "JIRA Issue Workflow" page on the OpenMRS Wiki. [2].
Michael
[0] http://producingoss.com/en/bug-tracker-usage.html
[1] https://wiki.openmrs.org/display/RES/JIRA+Issue+Workflow
________________________________
Click here to
unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l>
from OpenMRS Developers' mailing list
