Re: Mesos Jira workflow
Folks, thanks to Tony Stevenson in INFRA, our Mesos workflow https://issues.apache.org/jira/secure/attachment/12740454/Mesos%20Workflow.png now reflects the one we arrived at. Due to some quirks in Jira, the transitions buttons shown at the top of the issue may not always reflect a valid transition (we're looking into this with Tony): for example, an Accepted story has a Stop Progress button (makes no sense); if you hit it, you'll get an error message - which is correct, but annoying (also, really, we would like a Start Progress button!). For the time being, please use the Workflow button (which offers a subset of possible states to transition to) to move Issues across states. We'll keep you updated on progress. The INFRA ticket to follow is here: https://issues.apache.org/jira/browse/INFRA-9846 *Marco Massenzio* *Distributed Systems Engineer* 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*
Re: Mesos Jira workflow
Hey Marco, Thanks for doing this! +1 removing “closed” +1 to go back from “Reviewable” to “In Progress” +1 to go from “In Progress” to “Accepted” instead of “Open” +1 Removing “Reopened On 09 Jun 2015, at 23:26, 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: (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
Re: Mesos Jira workflow
+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*
Re: Mesos Jira workflow
For the ASF Jira we do not allow special permissions for customizing or changing settings, we have been down that road before and it turned into a mess. There are some settings within the ASF Jira which are global to all projects and can not be changed, but you can have a custom workflow and transitions. Happy to help with this once a final workflow is settled on (this will also impact your agile boards in use) -Jake On Tue, Jun 9, 2015 at 6:41 PM, Marco Massenzio ma...@mesosphere.io wrote: Hi Vinod, thanks for super-quick reply. We've already been through this in our internal (Mesosphere) Jira (on a completely different topic) so I know that this can be done, if we use our own custom Mesos workflow (here: https://issues.apache.org/jira/plugins/servlet/project-config/MESOS/workflows) which I think we already do. I would probably need to be given adequate permissions to modify it (avoiding to mess up in the process the entirety of ASF :) Once we agree that the proposed one works for folks here, I'll work with Jake and Infra folks, and figure out how to implement. Thanks! *Marco Massenzio* *Distributed Systems Engineer* On Tue, Jun 9, 2015 at 3:15 PM, Vinod Kone vinodk...@apache.org wrote: +jake Marco, this sounds good to me. Have you looked into see if JIRA allows us to constrain ourselves to this workflow? If yes, the next step would be to work with ASF infra to see if they are ok with us adopting a new workflow. IIRC, there are some JIRA settings that are global to all ASF projects and hence can't be customized. On Tue, Jun 9, 2015 at 3:00 PM, Marco Massenzio ma...@mesosphere.io 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 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*
Re: Mesos Jira workflow
Very helpful Marco… I like the idea of tightening our JIRA workflow. +1 removing “closed +1 “reviewable” back to in progress — to me this is a very helpful signal for longer lasting comment addressing +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” ? +1 removing “reopened as it has no extra value for us 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 ma...@mesosphere.io 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 ma...@mesosphere.io mailto: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: (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
Re: Mesos Jira workflow
+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*
Re: Mesos Jira workflow
Inline... On Tue, Jun 9, 2015 at 4:56 PM, Benjamin Mahler benjamin.mah...@gmail.com wrote: I don't have comment permissions on the doc, but it looks like you omitted a way to go from Reviewable - In Progress, which we often do when the reviewee has more work to do before being ready for additional reviews, for example. Great catch - added! (called it `fix` - anyone has any suggestions for something more suggestive?) I'm not sure what 'Closed' is supposed to represent, what does it mean to go from Resolved to Closed? Great question! I don't know (it was there, and I thought it worth leaving) In my previous experience, we used it to mark it as QA Certified In other words - developer(s) would run and test locally (or in Jenkins, or whatever) and mark the bug/story as Resolved - but it would only be declared Closed (and make it to the Release Notes) once QA had it tested against regressions, etc. I'm happy to remove it from the workflow (assuming Jira allows it) or we can leave it there. On Tue, Jun 9, 2015 at 3:41 PM, Marco Massenzio ma...@mesosphere.io wrote: Hi Vinod, thanks for super-quick reply. We've already been through this in our internal (Mesosphere) Jira (on a completely different topic) so I know that this can be done, if we use our own custom Mesos workflow (here: https://issues.apache.org/jira/plugins/servlet/project-config/MESOS/workflows ) which I think we already do. I would probably need to be given adequate permissions to modify it (avoiding to mess up in the process the entirety of ASF :) Once we agree that the proposed one works for folks here, I'll work with Jake and Infra folks, and figure out how to implement. Thanks! *Marco Massenzio* *Distributed Systems Engineer* On Tue, Jun 9, 2015 at 3:15 PM, Vinod Kone vinodk...@apache.org wrote: +jake Marco, this sounds good to me. Have you looked into see if JIRA allows us to constrain ourselves to this workflow? If yes, the next step would be to work with ASF infra to see if they are ok with us adopting a new workflow. IIRC, there are some JIRA settings that are global to all ASF projects and hence can't be customized. On Tue, Jun 9, 2015 at 3:00 PM, Marco Massenzio ma...@mesosphere.io 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 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*
Re: Mesos Jira workflow
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 ma...@mesosphere.io wrote: On Wed, Jun 10, 2015 at 1:15 AM, Till Toenshoff toensh...@me.com 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 ma...@mesosphere.io 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 ma...@mesosphere.io mailto: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: (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
Re: Mesos Jira workflow
On Wed, Jun 10, 2015 at 1:15 AM, Till Toenshoff toensh...@me.com 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 ma...@mesosphere.io 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 ma...@mesosphere.io mailto: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: (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
Re: Mesos Jira workflow
inline... 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. I thought about it and it occurs to me that there are three reasons why one would Stop Progress: 1. I haven't got time, and more important stuff came along (this is the case your question seems to imply) 2. I looked into it, and it really doesn't seem worth/desirable to do, ever (covered in Resolved - won't fix) 3. I looked into it, and I have my doubts this may ever be desirable, but I'll leave it to others to decide (the current Stop Progress) I've added a Pause Progress transition (back to Accepted) that covers case #1 - would this work? 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. Sure - added. 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. Got rid of Closed. As both Bens don't like it - I think it was doomed :) 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*
Re: Mesos Jira workflow
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*
Re: Mesos Jira workflow
To go from accepted to open you need to go through in progress? On Wed, Jun 10, 2015 at 2:16 PM, Marco Massenzio ma...@mesosphere.io 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 ma...@mesosphere.io wrote: On Wed, Jun 10, 2015 at 1:15 AM, Till Toenshoff toensh...@me.com 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 ma...@mesosphere.io 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 ma...@mesosphere.io mailto: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: (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
Re: Mesos Jira workflow
Don't forget that folks accidentally do things all the time in JIRA, so if you fence off the ability to go back you make an accident permanent, or does JIRA have some undo support I'm unaware of? On Wed, Jun 10, 2015 at 6:33 PM, Marco Massenzio ma...@mesosphere.io wrote: On Wed, Jun 10, 2015 at 6:19 PM, Benjamin Mahler benjamin.mah...@gmail.com 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 ma...@mesosphere.io 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 ma...@mesosphere.io wrote: On Wed, Jun 10, 2015 at 1:15 AM, Till Toenshoff toensh...@me.com 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 ma...@mesosphere.io 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 ma...@mesosphere.io mailto: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: (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
Re: Mesos Jira workflow
On Wed, Jun 10, 2015 at 6:44 PM, Benjamin Mahler benjamin.mah...@gmail.com wrote: Don't forget that folks accidentally do things all the time in JIRA, or in life :) eh eh I never forget that so if you fence off the ability to go back you make an accident permanent, or does JIRA have some undo support I'm unaware of? I am pretty sure that we can alter the state of a given issue to move it back to 'Open' (even if, as you pointed out, we need to take a detour via 'in progress') - but let me do some investigation and figure this one out. Thanks! On Wed, Jun 10, 2015 at 6:33 PM, Marco Massenzio ma...@mesosphere.io wrote: On Wed, Jun 10, 2015 at 6:19 PM, Benjamin Mahler benjamin.mah...@gmail.com 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 ma...@mesosphere.io 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 ma...@mesosphere.io wrote: On Wed, Jun 10, 2015 at 1:15 AM, Till Toenshoff toensh...@me.com 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 ma...@mesosphere.io 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 ma...@mesosphere.io mailto: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: (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
Re: Mesos Jira workflow
On Wed, Jun 10, 2015 at 6:19 PM, Benjamin Mahler benjamin.mah...@gmail.com 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 ma...@mesosphere.io 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 ma...@mesosphere.io wrote: On Wed, Jun 10, 2015 at 1:15 AM, Till Toenshoff toensh...@me.com 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 ma...@mesosphere.io 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 ma...@mesosphere.io mailto: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: (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
Mesos Jira workflow
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*
Re: Mesos Jira workflow
I don't have comment permissions on the doc, but it looks like you omitted a way to go from Reviewable - In Progress, which we often do when the reviewee has more work to do before being ready for additional reviews, for example. I'm not sure what 'Closed' is supposed to represent, what does it mean to go from Resolved to Closed? On Tue, Jun 9, 2015 at 3:41 PM, Marco Massenzio ma...@mesosphere.io wrote: Hi Vinod, thanks for super-quick reply. We've already been through this in our internal (Mesosphere) Jira (on a completely different topic) so I know that this can be done, if we use our own custom Mesos workflow (here: https://issues.apache.org/jira/plugins/servlet/project-config/MESOS/workflows) which I think we already do. I would probably need to be given adequate permissions to modify it (avoiding to mess up in the process the entirety of ASF :) Once we agree that the proposed one works for folks here, I'll work with Jake and Infra folks, and figure out how to implement. Thanks! *Marco Massenzio* *Distributed Systems Engineer* On Tue, Jun 9, 2015 at 3:15 PM, Vinod Kone vinodk...@apache.org wrote: +jake Marco, this sounds good to me. Have you looked into see if JIRA allows us to constrain ourselves to this workflow? If yes, the next step would be to work with ASF infra to see if they are ok with us adopting a new workflow. IIRC, there are some JIRA settings that are global to all ASF projects and hence can't be customized. On Tue, Jun 9, 2015 at 3:00 PM, Marco Massenzio ma...@mesosphere.io 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 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*
Re: Mesos Jira workflow
Hi Vinod, thanks for super-quick reply. We've already been through this in our internal (Mesosphere) Jira (on a completely different topic) so I know that this can be done, if we use our own custom Mesos workflow (here: https://issues.apache.org/jira/plugins/servlet/project-config/MESOS/workflows) which I think we already do. I would probably need to be given adequate permissions to modify it (avoiding to mess up in the process the entirety of ASF :) Once we agree that the proposed one works for folks here, I'll work with Jake and Infra folks, and figure out how to implement. Thanks! *Marco Massenzio* *Distributed Systems Engineer* On Tue, Jun 9, 2015 at 3:15 PM, Vinod Kone vinodk...@apache.org wrote: +jake Marco, this sounds good to me. Have you looked into see if JIRA allows us to constrain ourselves to this workflow? If yes, the next step would be to work with ASF infra to see if they are ok with us adopting a new workflow. IIRC, there are some JIRA settings that are global to all ASF projects and hence can't be customized. On Tue, Jun 9, 2015 at 3:00 PM, Marco Massenzio ma...@mesosphere.io 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 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*
Re: Mesos Jira workflow
+jake Marco, this sounds good to me. Have you looked into see if JIRA allows us to constrain ourselves to this workflow? If yes, the next step would be to work with ASF infra to see if they are ok with us adopting a new workflow. IIRC, there are some JIRA settings that are global to all ASF projects and hence can't be customized. On Tue, Jun 9, 2015 at 3:00 PM, Marco Massenzio ma...@mesosphere.io 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 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*
Re: Mesos Jira workflow
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 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*
