inline... On Wed, Jun 10, 2015 at 12:44 AM, Adam Bordelon <a...@mesosphere.io> wrote:
> +1 to removing Closed. In other projects, I've seen Resolved mean that a > supposed fix has been committed, and Closed means that somebody (QA? > Reporter?) has verified the fix, but we don't wait for verification, so > it's probably pointless for us. > yep, gone. > +1 to removing Reopened, and just going back to Open/Accepted instead. > +1 to BenH's request to be able to Resolve from any status, so that an Open > issue can be quickly resolved as Duplicate or Won't Fix. > added. > We'll need to continue educating users about what "Accepted" means, > especially if it becomes a required transition. Is there a way that we can > require the Shepherd field to be filled out before something can be > Accepted? > I don't think there is (and, to be honest, I am hesitant to require a "Shepherd" for the transition: it seems too high a bar - I'd suggest to require a Shepherd for the transition to In Progress). But totally +1 on educating the community about the semantics of "Accepted" (especially, the requirement of clear, well-written feature descriptions/bug reports) > > On Tue, Jun 9, 2015 at 11:29 PM, Benjamin Hindman <b...@eecs.berkeley.edu> > wrote: > > > +1 This sounds great to me Marco. I love eliminating Reopened, as well as > > simplifying (constraining) other transitions. I couple of quick > questions: > > > > Why does stoping progress go from In Progress back to Open instead of > > Accepted? Seems like it's still an Accepted issue just not being worked > on. > > > > Can we resolve or close something directly from Open? For example, issues > > we're never going to work on or are duplicates or already fixed, etc. > > > > Do we need both Resolved and Closed? This has come up in the past, we > tend > > to close issues after we cut a release with them, but it's kind of an > extra > > step that I'm not convinced we really need to do. > > > > > > > > On Tue, Jun 9, 2015 at 2:26 PM Marco Massenzio <ma...@mesosphere.io> > > wrote: > > > >> Folks, > >> > >> Please take a look at MESOS-2806: in a nutshell, our current workflow is > >> rather convoluted and brings about a host of issues, when managing > tasks' > >> status transitions (detailed in the Jira - see screenshots there). > >> > >> This is what it currently looks like: > >> > >> [image: Inline image 1] > >> > >> (spaghetti workflow? :) > >> > >> I would propose to simplify it to the following: > >> > >> [image: Inline image 2] > >> > >> I'm sure we can think up all sorts of corner cases, but I would submit > >> that simplicity would trump complexity and allow us to track progress > (or > >> lack thereof) of stories/tasks/bugs in a much more punctual manner. > >> > >> Anyone against it? > >> > >> *Marco Massenzio* > >> *Distributed Systems Engineer* > >> > > >
