Re: Adding/Using More Resolution Types on JIRA
Some examples to illustrate my point. A couple of issues from the oldest open issues in the SQL component: [SQL] spark-sql exits while encountered an error https://issues.apache.org/jira/browse/SPARK-4572 This is an incomplete report that nobody can take action on. It can be resolved as Incomplete, instead of Inactive. In fact, there is no need to wait that much to close it as Incomplete. Using a field in a WHERE clause that is not in the schema does not throw an exception https://issues.apache.org/jira/browse/SPARK-5305 This is also Incomplete, it is not reproducible currently and it is missing version info. Rather than a need of these new statuses, it seems that there is a need of more people assessing and triaging new issues. Best, -- Santiago M. Mola http://www.stratio.com/ Vía de las dos Castillas, 33, Ática 4, 3ª Planta 28224 Pozuelo de Alarcón, Madrid Tel: +34 91 828 6473 // www.stratio.com // *@stratiobd https://twitter.com/StratioBD*
Re: Adding/Using More Resolution Types on JIRA
On Thu, May 21, 2015 at 9:06 PM, Santiago Mola sm...@stratio.com wrote: Inactive - A feature or bug that has had no activity from users or developers in a long time Why is this needed? Every JIRA listing can be sorted by activity. That gets the inactive ones out of your view quickly. I do not see any reason why an issue should be closed because of this. If it's inactive, maybe it's because it falls on some of the other categories (out of scope, later, won't fix). I don't think sorting helps or that browsing is the issue. What if you're searching for Open Critical issues concerning Pyspark? If the list is full of issues that are actually out of scope, later, won't fix, then that's a problem. That is a much more specific case than Inactivity, and a lot of large scale open source projects use specific resolutions for this. Yes, that's CannotReproduce. I think the walking-dead JIRAs we have in mind are some combination of: a JIRA opened without a lot of detail, that might or might not be a problem, nobody else seemed to have the problem and/or nobody cared to investigate, much has changed since anyway so might be obsolete. WontFix, CannotReproduce, NotAProblem are all possibly reasonable resolutions. If this is just about semantics, I also don't feel a strong need for a new state. On a more general note: what is the problem with open issues / pull requests? I see a tendency in the Spark project to do unusual things with issues / PRs just to maintain the numbers low. For example, closing PRs after a couple of weeks of inactivity just to shrink the queue or closing active issues just for the shake of it. Honestly, this looks a lot like trying to game metrics. But maybe there is something that I am missing. Game for whose benefit? nobody is being evaluated on this stuff. This is being proposed for real reasons, not for fun. A bunch of JIRA cruft is a symptom, not a cause. Something is wrong somewhere if people file JIRAs and they go nowhere. Everyone's time is wasted and with no conclusion, there's no feedback or learning anywhere. So it keeps happening. Is it bad JIRAs? scope issues? lack of follow up from developer or contributor? all of the above? I actually think it's mostly bad JIRAs: too large, too invasive, not that useful, hacky fixes to a facet of a problem, incomplete description, duplicate, etc. I think it's more useful to actually close these to communicate back clearly what is not going to be accepted. Things can be reopened if needed. Silently ignoring them forever as an Open JIRA seems less constructive. Maybe what it is actually needed is to improve the lifecycle of an issue while it is alive, instead of trying to kill it earlier. Some examples of this that are used on other projects are the incomplete status to signal that there is more info required from the reporter in order to take further action. Also confirmed to acknowledge that a bug is confirmed to be present and needs action by a developer. Yes, best to try to make the process better. That's why I started with things like a more comprehensive https://cwiki.apache.org/confluence/display/SPARK/Contributing+to+Spark to make better contributions in the first place. By the time dead JIRAs are closed, something's already gone wrong and time has been wasted. But we still need that culture of not letting stuff sit around. I don't mind the idea of an Unresolved InformationNeeded status, yeah. I don't actually think that would solve a problem though. The dead JIRAs are ones that never got any follow up, or, that got a lot of follow-up from the contributor but aren't going to be merged. - To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org
Re: Adding/Using More Resolution Types on JIRA
2015-05-12 9:50 GMT+02:00 Patrick Wendell pwend...@gmail.com: Inactive - A feature or bug that has had no activity from users or developers in a long time Why is this needed? Every JIRA listing can be sorted by activity. That gets the inactive ones out of your view quickly. I do not see any reason why an issue should be closed because of this. If it's inactive, maybe it's because it falls on some of the other categories (out of scope, later, won't fix). I can only think about a case where closing an inactive issue makes sense: * A bug was reported long time ago. Nobody was able to reproduce (after trying actively) and the reporter is no longer around to provide more info. That is a much more specific case than Inactivity, and a lot of large scale open source projects use specific resolutions for this. On a more general note: what is the problem with open issues / pull requests? I see a tendency in the Spark project to do unusual things with issues / PRs just to maintain the numbers low. For example, closing PRs after a couple of weeks of inactivity just to shrink the queue or closing active issues just for the shake of it. Honestly, this looks a lot like trying to game metrics. But maybe there is something that I am missing. Maybe what it is actually needed is to improve the lifecycle of an issue while it is alive, instead of trying to kill it earlier. Some examples of this that are used on other projects are the incomplete status to signal that there is more info required from the reporter in order to take further action. Also confirmed to acknowledge that a bug is confirmed to be present and needs action by a developer. Best, -- Santiago M. Mola http://www.stratio.com/ Vía de las dos Castillas, 33, Ática 4, 3ª Planta 28224 Pozuelo de Alarcón, Madrid Tel: +34 91 828 6473 // www.stratio.com // *@stratiobd https://twitter.com/StratioBD*
Re: Adding/Using More Resolution Types on JIRA
On Thu, May 21, 2015 at 10:03 PM, Santiago Mola sm...@stratio.com wrote: Sure. That is why I was talking about the Inactive resolution specifically. The combination of Priority + other statuses are enough to solve these issues. A minor/trivial issue that is incomplete is probably not going to hurt much to someone looking for critical open issues. If you mean you intend to consider them resolved, then yeah we agree a lot. The names of the resolved states don't matter nearly so much to me. For instance, in your examples, I could call those CannotReproduce or Incomplete. I would not want to leave them Open in that state indefinitely. On a side-note, I would like to contribute some time on improving this. When identifying this kind of issue, should I ask in the issue itself to resolve it in a specific way? I think reviewing JIRAs actually contributes to a better overall process, so I'd just dive in. Anything to advance a JIRA / PR to a resolution is very helpful. Ask for more info, investigate a problem to confirm it or fail to reproduce, propose a fix, identify duplicates, flag JIRAs for closing, review changes, say you think the change is good, etc. -- among the most helpful things anyone can do right now IMHO. - To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org
Re: Adding/Using More Resolution Types on JIRA
If there is no further feedback on this I will ask ASF Infra to add the new fields Out of Scope and Inactive. - Patrick On Tue, May 12, 2015 at 9:02 AM, Nicholas Chammas nicholas.cham...@gmail.com wrote: I tend to find that any large project has a lot of walking dead JIRAs, and pretending they are simply Open causes problems. Any state is better for these, so I favor this. Agreed. Inactive: A way to clear out inactive/dead JIRA's without indicating a decision has been made one way or the other. This is a good idea, and perhaps the process of closing JIRAs as Inactive can be automated. If nothing about a JIRA has changed in 12 months or more (e.g. current oldest open Spark issue; dates to Aug 2013: SPARK-867), perhaps a bot can mark it as such for us. (Here's a list of stale issues). This doesn't mean the issue is invalid or won't be addressed, but it gets it out of the Open queue, which ideally should be a high churn queue (e.g. stuff doesn't stay in there forever). Nick On Tue, May 12, 2015 at 4:49 AM Sean Owen so...@cloudera.com wrote: I tend to find that any large project has a lot of walking dead JIRAs, and pretending they are simply Open causes problems. Any state is better for these, so I favor this. The possible objection is that this will squash or hide useful issues, but in practice we have the opposite problem. Resolved issues are still searchable by default, and, people aren't shy about opening duplicates anyway. At least the semantics Later do not discourage a diligent searcher from considering commenting on and reopening such an archived JIRA. Patrick this could piggy back on INFRA-9513. As a corollary I would welcome deciding that Target Version should be used more narrowly to mean 'I really mean to help resolve this for the indicated version'. Setting it to a future version just to mean Later should instead turn into resolving the JIRA. Last: if JIRAs are regularly ice-boxed this way, I think it should trigger some reflection. Why are these JIRAs going nowhere? For completely normal reasons or does it mean too many TODOs are filed and forgotten? That's no comment on the current state, just something to watch. So: yes I like the idea. On May 12, 2015 8:50 AM, Patrick Wendell pwend...@gmail.com wrote: In Spark we sometimes close issues as something other than Fixed, and this is an important part of maintaining our JIRA. The current resolution types we use are the following: Won't Fix - bug fix or (more often) feature we don't want to add Invalid - issue is underspecified or not appropriate for a JIRA issue Duplicate - duplicate of another JIRA Cannot Reproduce - bug that could not be reproduced Not A Problem - issue purports to represent a bug, but does not I would like to propose adding a few new resolutions. This will require modifying the ASF JIRA, but infra said they are open to proposals as long as they are considered of broad interest. My issue with the current set of resolutions are that Won't Fix is a big catch all we use for many different things. Most often it's used for things that aren't even bugs even though it has Fix in the name. I'm proposing adding: Inactive - A feature or bug that has had no activity from users or developers in a long time Out of Scope - A feature proposal that is not in scope given the projects goals Later - A feature not on the immediate roadmap, but potentially of interest longer term (this one already exists, I'm just proposing to start using it) I am in no way proposing changes to the decision making model around JIRA's, notably that it is consensus based and that all resolutions are considered tentative and fully reversible. The benefits I see of this change would be the following: 1. Inactive: A way to clear out inactive/dead JIRA's without indicating a decision has been made one way or the other. 2. Out of Scope: It more clearly explains closing out-of-scope features than the generic Won't Fix. Also makes it more clear to future contributors what is considered in scope for Spark. 3. Later: A way to signal that issues aren't targeted for a near term version. This would help avoid the mess we have now of like 200+ issues targeted at each version and target version being a very bad indicator of actual roadmap. An alternative on this one is to have a version called Later or Parking Lot but not close the issues. Any thoughts on this? - Patrick - To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org - To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org
Adding/Using More Resolution Types on JIRA
In Spark we sometimes close issues as something other than Fixed, and this is an important part of maintaining our JIRA. The current resolution types we use are the following: Won't Fix - bug fix or (more often) feature we don't want to add Invalid - issue is underspecified or not appropriate for a JIRA issue Duplicate - duplicate of another JIRA Cannot Reproduce - bug that could not be reproduced Not A Problem - issue purports to represent a bug, but does not I would like to propose adding a few new resolutions. This will require modifying the ASF JIRA, but infra said they are open to proposals as long as they are considered of broad interest. My issue with the current set of resolutions are that Won't Fix is a big catch all we use for many different things. Most often it's used for things that aren't even bugs even though it has Fix in the name. I'm proposing adding: Inactive - A feature or bug that has had no activity from users or developers in a long time Out of Scope - A feature proposal that is not in scope given the projects goals Later - A feature not on the immediate roadmap, but potentially of interest longer term (this one already exists, I'm just proposing to start using it) I am in no way proposing changes to the decision making model around JIRA's, notably that it is consensus based and that all resolutions are considered tentative and fully reversible. The benefits I see of this change would be the following: 1. Inactive: A way to clear out inactive/dead JIRA's without indicating a decision has been made one way or the other. 2. Out of Scope: It more clearly explains closing out-of-scope features than the generic Won't Fix. Also makes it more clear to future contributors what is considered in scope for Spark. 3. Later: A way to signal that issues aren't targeted for a near term version. This would help avoid the mess we have now of like 200+ issues targeted at each version and target version being a very bad indicator of actual roadmap. An alternative on this one is to have a version called Later or Parking Lot but not close the issues. Any thoughts on this? - Patrick - To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org
Re: Adding/Using More Resolution Types on JIRA
I tend to find that any large project has a lot of walking dead JIRAs, and pretending they are simply Open causes problems. Any state is better for these, so I favor this. Agreed. 1. Inactive: A way to clear out inactive/dead JIRA’s without indicating a decision has been made one way or the other. This is a good idea, and perhaps the process of closing JIRAs as Inactive can be automated. If *nothing* about a JIRA has changed in 12 months or more (e.g. current oldest open Spark issue; dates to Aug 2013: SPARK-867 https://issues.apache.org/jira/browse/SPARK-867), perhaps a bot can mark it as such for us. (Here’s a list of stale issues https://issues.apache.org/jira/browse/SPARK-867?jql=project%20=%20SPARK%20AND%20resolution%20=%20Unresolved%20AND%20updated%20%3C=%20-26w%20ORDER%20BY%20updated%20ASC ). This doesn’t mean the issue is invalid or won’t be addressed, but it gets it out of the “Open” queue, which ideally should be a high churn queue (e.g. stuff doesn’t stay in there forever). Nick On Tue, May 12, 2015 at 4:49 AM Sean Owen so...@cloudera.com wrote: I tend to find that any large project has a lot of walking dead JIRAs, and pretending they are simply Open causes problems. Any state is better for these, so I favor this. The possible objection is that this will squash or hide useful issues, but in practice we have the opposite problem. Resolved issues are still searchable by default, and, people aren't shy about opening duplicates anyway. At least the semantics Later do not discourage a diligent searcher from considering commenting on and reopening such an archived JIRA. Patrick this could piggy back on INFRA-9513. As a corollary I would welcome deciding that Target Version should be used more narrowly to mean 'I really mean to help resolve this for the indicated version'. Setting it to a future version just to mean Later should instead turn into resolving the JIRA. Last: if JIRAs are regularly ice-boxed this way, I think it should trigger some reflection. Why are these JIRAs going nowhere? For completely normal reasons or does it mean too many TODOs are filed and forgotten? That's no comment on the current state, just something to watch. So: yes I like the idea. On May 12, 2015 8:50 AM, Patrick Wendell pwend...@gmail.com wrote: In Spark we sometimes close issues as something other than Fixed, and this is an important part of maintaining our JIRA. The current resolution types we use are the following: Won't Fix - bug fix or (more often) feature we don't want to add Invalid - issue is underspecified or not appropriate for a JIRA issue Duplicate - duplicate of another JIRA Cannot Reproduce - bug that could not be reproduced Not A Problem - issue purports to represent a bug, but does not I would like to propose adding a few new resolutions. This will require modifying the ASF JIRA, but infra said they are open to proposals as long as they are considered of broad interest. My issue with the current set of resolutions are that Won't Fix is a big catch all we use for many different things. Most often it's used for things that aren't even bugs even though it has Fix in the name. I'm proposing adding: Inactive - A feature or bug that has had no activity from users or developers in a long time Out of Scope - A feature proposal that is not in scope given the projects goals Later - A feature not on the immediate roadmap, but potentially of interest longer term (this one already exists, I'm just proposing to start using it) I am in no way proposing changes to the decision making model around JIRA's, notably that it is consensus based and that all resolutions are considered tentative and fully reversible. The benefits I see of this change would be the following: 1. Inactive: A way to clear out inactive/dead JIRA's without indicating a decision has been made one way or the other. 2. Out of Scope: It more clearly explains closing out-of-scope features than the generic Won't Fix. Also makes it more clear to future contributors what is considered in scope for Spark. 3. Later: A way to signal that issues aren't targeted for a near term version. This would help avoid the mess we have now of like 200+ issues targeted at each version and target version being a very bad indicator of actual roadmap. An alternative on this one is to have a version called Later or Parking Lot but not close the issues. Any thoughts on this? - Patrick - To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org
Re: Adding/Using More Resolution Types on JIRA
I tend to find that any large project has a lot of walking dead JIRAs, and pretending they are simply Open causes problems. Any state is better for these, so I favor this. The possible objection is that this will squash or hide useful issues, but in practice we have the opposite problem. Resolved issues are still searchable by default, and, people aren't shy about opening duplicates anyway. At least the semantics Later do not discourage a diligent searcher from considering commenting on and reopening such an archived JIRA. Patrick this could piggy back on INFRA-9513. As a corollary I would welcome deciding that Target Version should be used more narrowly to mean 'I really mean to help resolve this for the indicated version'. Setting it to a future version just to mean Later should instead turn into resolving the JIRA. Last: if JIRAs are regularly ice-boxed this way, I think it should trigger some reflection. Why are these JIRAs going nowhere? For completely normal reasons or does it mean too many TODOs are filed and forgotten? That's no comment on the current state, just something to watch. So: yes I like the idea. On May 12, 2015 8:50 AM, Patrick Wendell pwend...@gmail.com wrote: In Spark we sometimes close issues as something other than Fixed, and this is an important part of maintaining our JIRA. The current resolution types we use are the following: Won't Fix - bug fix or (more often) feature we don't want to add Invalid - issue is underspecified or not appropriate for a JIRA issue Duplicate - duplicate of another JIRA Cannot Reproduce - bug that could not be reproduced Not A Problem - issue purports to represent a bug, but does not I would like to propose adding a few new resolutions. This will require modifying the ASF JIRA, but infra said they are open to proposals as long as they are considered of broad interest. My issue with the current set of resolutions are that Won't Fix is a big catch all we use for many different things. Most often it's used for things that aren't even bugs even though it has Fix in the name. I'm proposing adding: Inactive - A feature or bug that has had no activity from users or developers in a long time Out of Scope - A feature proposal that is not in scope given the projects goals Later - A feature not on the immediate roadmap, but potentially of interest longer term (this one already exists, I'm just proposing to start using it) I am in no way proposing changes to the decision making model around JIRA's, notably that it is consensus based and that all resolutions are considered tentative and fully reversible. The benefits I see of this change would be the following: 1. Inactive: A way to clear out inactive/dead JIRA's without indicating a decision has been made one way or the other. 2. Out of Scope: It more clearly explains closing out-of-scope features than the generic Won't Fix. Also makes it more clear to future contributors what is considered in scope for Spark. 3. Later: A way to signal that issues aren't targeted for a near term version. This would help avoid the mess we have now of like 200+ issues targeted at each version and target version being a very bad indicator of actual roadmap. An alternative on this one is to have a version called Later or Parking Lot but not close the issues. Any thoughts on this? - Patrick - To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org
