Re: [xwiki-devs] Reintroduce the Resolved state in JIRA

On Dec 6, 2007, at 5:22 PM, Ludovic Dubost wrote: 2 points: 1) I'd prefer a new state rather than Resolved. Something like "Tested" or "Externally Tested" or "Verified by Tester" or whatever

2) We'll need to write issues from a user point of view (which I've always wanted) and not from an internal point of view. This means that for each issue fixed technically we need to find a user use case that was failing because of it and use that as the description rather than a technical description. Otherwise an external tester won't be able to test it. anyway let's wait for a tester to come on board first... -Vincent > Maybe we can leave the decision on the project head for each of our > projects. > > Ludovic > > Vincent Massol wrote: >> On Dec 5, 2007, at 3:13 PM, Vincent Massol wrote: >> >> >>> I don't like it. >>> >>> The developer is reponsible for testing what he commits. Period. >>> Anything that implies otherwise should be banned IMO. >>> >> Just to qualify my answer a bit ;) >> >> It can work but only when there's a very rigid process with one >> person >> working full time to manage it. Unfortunately we don't have that >> person yet. Maybe in the future we'll be able to get someone to do >> functional tests for us. When this happens we could possibly add a >> new >> state for whether the issue has been validated by an external tester >> or not. But even when that happens every developer still needs to >> ensure that: >> 1) he's fully tested it (with automated tests as much as possible) >> 2) written documentation for it >> >> -Vincent >> >> >>> On Dec 5, 2007, at 2:54 PM, Sergiu Dumitriu wrote: >>> >>> >>>> No replies yet... >>>> >>>> On Oct 11, 2007 5:33 PM, Sergiu Dumitriu >>>> <sergiu.dumitriu(a)gmail.com> >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> We should reintroduce the Resolved state in the issue workflow, >>>>> and >>>>> it >>>>> should work like this: >>>>> >>>>> - When closing an issue, it will go in the Resolved state, which >>>>> means >>>>> that somebody provided a fix and it is committed in the >>>>> repository. >>>>> - Somebody else can test (manually) that the issue is indeed >>>>> fixed/implemented, and it works as expected. If no, then it goes >>>>> back >>>>> to Open, otherwise it goes to Verified. >>>>> - When all the needed tests and documentation are written, the >>>>> issue >>>>> can be closed completely, entering the Closed state. >>>>> >>>>> This should improve the way we write code, meaning that we don't >>>>> just >>>>> commit some quick fix code which nobody sees, and claim that the >>>>> issue >>>>> is fixed. Right now we're trying to do peer reviewing either by >>>>> first >>>>> attaching patches to the issue and have somebody review it, or by >>>>> hoping that someone is reading the commit mails and notices if >>>>> something is wrong. We should never make a release that has issues >>>>> in >>>>> the Resolved state, as it has unverified code, probably with >>>>> missing >>>>> documentation and proper tests. We should reserve a few days >>>>> before >>>>> each release for moving any Resolved issue to the Closed state, by >>>>> verifying, testing and documenting it. >>>>> >>>>> Verifying issues can be done by outsiders, too, so we could >>>>> involve >>>>> the community more. Perhaps it would be a good idea to require two >>>>> verifiers before moving the issue to verified, as testing on >>>>> different >>>>> systems can spot some bugs, like the full screen editor not >>>>> working >>>>> in >>>>> Safari issue.