It hasn’t been used so much so far, but on the bugs where it has I like being able to tell the difference. I don’t think we’d poke people about verification like we do with Radar, though, so we will (and have) end up with a lot of bugs left in Resolved/Verify.
Jordan > On Aug 15, 2016, at 10:10, Daniel Dunbar <daniel_dun...@apple.com> wrote: > > Do we anticipate Verify being used in practice much? > > Would it be better to simplify the workflow and just have a single > "Resolved/Closed/Done" state? If the originator does test the bug and find it > isn't fixed, they can reopen. > > My guess is not that many people are going to actively look at their JIRA > account to find bugs that they are supposed to be verifying. > > - Daniel > >> On Aug 15, 2016, at 10:08 AM, Jordan Rose via swift-build-dev >> <swift-build-...@swift.org <mailto:swift-build-...@swift.org>> wrote: >> >> Hi, swift-dev et al (but especially Ted). I’ve recently noticed that our >> JIRA workflow has been a bit confusing. We currently have five “statuses": >> >> 1. Opened: This bug has been filed. >> 2. In Progress: Someone is actively working on this bug. (Not everyone has >> been bothering to set this, but it seems reasonable to have.) >> 3. Resolved: A fix has been merged to master. >> 4. Closed: The fix has been verified by the reporter. >> 5. Reopened: The “fix" doesn’t actually fix the reporter’s problem. >> >> The problem is that the “Resolved” and “Closed” statuses aren’t really >> distinguished on the site itself—it’s unclear for a contributor which one >> they’re supposed to use when they get something merged, and it’s unclear for >> the reporter what they’re supposed to say. Therefore, I suggest changing the >> “Resolved” status to “Verify” (like we use in Radar) and the “Resolve Issue” >> button to “Mark Resolved”. >> >> (There are other things unspecified here, such as how to track what release >> a fix gets into, or what the story is for the Assignee field, but we can >> discuss those later.) >> >> What do you think? >> Thanks, >> Jordan >> _______________________________________________ >> swift-build-dev mailing list >> swift-build-...@swift.org <mailto:swift-build-...@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-build-dev >
_______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev