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 _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
