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 > > > > >
