On Wed, Jun 10, 2015 at 6:19 PM, Benjamin Mahler <[email protected]> wrote:
> To go from "accepted" to "open" you need to go through "in progress"? > > That part wasn't changed from before? Anyways, why would you ever want to do that? This means that, at some point we looked at something, thought we would want to do that (at some point in future) then, eventually, changed our mind (we no longer want to do it) but will think some more at some other future point and (maybe) re-accept it? This seems an unlikely scenario? more likely, you figured out it wasn't a good idea after all (or maybe it turned out to be a duplicate - or some other features took the problem away) and we can move directly to "resolved". Granted, we can obviously add an "unaccept" transition, but I would much prefer to keep this simple to avoid confusing people. (and, as you correctly pointed out, there is a path back to 'Open' if we really want to). On Wed, Jun 10, 2015 at 2:16 PM, Marco Massenzio <[email protected]> > wrote: > > > Thanks, everyone, for your suggestions: quick feedback was much > > appreciated! > > > > I've updated the Google Doc, I think we're in good shape, I'll wait until > > Friday to hear if anyone has still objections, then I'll work with Jake > > (thanks for offer to help!) to implement it. > > > > *Marco Massenzio* > > *Distributed Systems Engineer* > > > > On Wed, Jun 10, 2015 at 2:11 PM, Marco Massenzio <[email protected]> > > wrote: > > > > > > > > On Wed, Jun 10, 2015 at 1:15 AM, Till Toenshoff <[email protected]> > > wrote: > > > > > >> Very helpful Marco… I like the idea of tightening our JIRA workflow. > > >> > > >> +1 removing “closed" > > >> > > > done > > > > > > > > >> +1 “reviewable” back to "in progress" — to me this is a very helpful > > >> signal for longer lasting comment addressing > > >> > > > done > > > > > > > > >> +1 making sure that “accepted" is the gatekeeper and includes > assigning > > >> the maintainer as a default shepherd — should we even go as far as to > > >> prevent “assigning” issues that have not gotten “accepted” and > > “shepherd > > >> assigned” ? > > >> > > > > > > let's not gate fixing the workflow to my achieving the next level of > > > Jira-Wizardry :) > > > the goal can be achieved by education (and enforcement of the policy) > > > > > > I am totally in favor of asking folks NOT to work on non-accepted > stories > > > (or, conversely, if they come across issues that are NOT accepted, but > > want > > > to do work and/or investigation, to assign to themselves and move to > > > "accepted" state). > > > > > > +1 removing “reopened" as it has no extra value for us > > >> > > >> it's history! > > > > > > > > >> Resolving without accepting to me sounds like a shortcut that we might > > >> want to prevent as it could be a bad example? > > >> > > >> > On Jun 10, 2015, at 12:00 AM, Marco Massenzio <[email protected]> > > >> wrote: > > >> > > > >> > Hadn't realized that the mailing list forwarder would make the > images > > >> unavailable, apologies about that. > > >> > > > >> > I've created this Google Doc < > > >> > > > https://docs.google.com/document/d/1KQIyEzFP3LF05FkW81SYcG50-HaACD2u-f2SPVAERI8/edit > > > > > >> which should be open and accessible. > > >> > > > >> > Again, please let me know if anyone feels strongly that we should > keep > > >> the current workflow. > > >> > Thanks! > > >> > > > >> > Marco Massenzio > > >> > Distributed Systems Engineer > > >> > > > >> > On Tue, Jun 9, 2015 at 2:26 PM, Marco Massenzio < > [email protected] > > >> <mailto:[email protected]>> 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: > > >> > > > >> > > > >> > > > >> > (spaghetti workflow? :) > > >> > > > >> > I would propose to simplify it to the following: > > >> > > > >> > > > >> > > > >> > 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 > > >> > > > >> > > >> > > > > > >
