+a million for Needs Verification and Documentation
Having something built into the ticket workflows where developers have to explicitly think to themselves 'I'm not going to document this', seems like it might encourage better behaviour. (I'm as guilty as anyone) d On Wed, Feb 8, 2012 at 8:33 AM, Mark Goodrich <[email protected]> wrote: > After trying Rafal’s suggestion of creating TEST tickets, I still think > I’d like to add new JIRA workflow state.**** > > ** ** > > What would people think of the following new state:**** > > ** ** > > Needs Verification and Documentation – with the following transitions:**** > > Rework Needed (Assign issue) -> In Progress**** > > Verify and Close (No screen) -> Closed**** > > Cancel Issue (Close issue with reason and fixVersion) -> Closed**** > > ** ** > > Then add a new transition to the Approved state:**** > > Request Verification (No screen) -> Needs Verification and Documentation** > ** > > ** ** > > And the same new transition to the Code Review (Post-Commit)**** > > Request Verification (No screen) -> Needs Verification and Documentation** > ** > > ** ** > > The man use case is that the ticket is in Committed Code state, and the > code has been reviewed and approved, but the project administrator would > like further verification and documentation. Therefore, instead of > choosing “Approve & Close” the admin would choose “Request Verification”. > The admin would add a comment as to who is responsible for verification > (instead of changing the assignee). Typical people asked to do > verification would be: 1) a QA resource, 2) the reporter, 3) the assignee. > **** > > ** ** > > Thoughts?**** > > Mark**** > > ** ** > > ** ** > > *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Michael > Seaton > *Sent:* Friday, February 03, 2012 3:11 PM > *To:* [email protected] > *Subject:* Re: [OPENMRS-DEV] JIRA: Awaiting Testing Verification state?*** > * > > ** ** > > It's actually been my experience that our code review process is often so > focused on the actual code, it doesn't always focus as much on whether the > developed product (UI features, etc) works right or meets all of the > initial specifications. Separating the process into code review (typically > "the code looks good, the design is good, you have unit tests, you follow > the right patterns", etc) and functional testing/approval might explicitly > ensure that these steps are always being followed better. > > > On 02/03/2012 02:51 PM, Darius Jazayeri wrote: **** > > Mark's point is that sometimes there's a separate QA/QC team (in the case > of this sprint, it's an awesome PIH volunteer named Cordt). That's an > extra, higher level of testing than what happens during our regular ticket > workflow. **** > > ** ** > > And since we don't have a QA/QC team for OpenMRS generally, we obviously > haven't modeled the "to-be-tested-by-QA-QC.**** > > ** ** > > Another option would be to approve the ticket and add a label for > "needs-QA". Once that QA has happened, then remove the label and possibly > reopen the ticket, or create a new ticket.**** > > ** ** > > -Darius**** > > On Fri, Feb 3, 2012 at 11:29 AM, Michael Downey <[email protected]> > wrote:**** > > Shouldn't a post-commit code review also be ensuring the code change > actually fixed the problem? > > Michael > > _________________________________________ > > 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]**** > > ** ** > ------------------------------ > > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > **** > ------------------------------ > > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > **** > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list _________________________________________ 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]
