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
