+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. +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. 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?
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* >> >
