----- Original Message -----
> >> Another thing is that we should, IMO, err on the side of explicitly saying > >> "no" or "not yet" to patches, rather than letting them linger without > >> attention. We do get patches where the user is well intentioned, but it is > > > > Completely agree. The solution is partly more supply of committer time > > on JIRAs. But that is detracting from the work the committers > > themselves want to do. More of the solution is reducing demand by > > helping people create useful, actionable, non-duplicate JIRAs from the > > start. Or encouraging people to resolve existing JIRAs and shepherding > > those in. > > saying no/not-yet is a vitally important piece of information. +1, when I propose a contribution to a project, I consider an articulate (and hopefully polite) "no thanks", or "not-yet", or "needs-work", to be far more useful and pleasing than just radio silence. It allows me to either address feedback, or just move on. Although it takes effort to keep abreast of community contributions, I don't think it needs to be an overbearing or heavy-weight process. I've seen other communities where they talked themselves out of better management because they conceived the ticket workflow as being more effort than it needed to be. Much better to keep ticket triage and workflow fast/simple, but actually do it. > > > > Elsewhere, I've found people reluctant to close JIRA for fear of > > offending or turning off contributors. I think the opposite is true. > > There is nothing wrong with "no" or "not now" especially accompanied > > with constructive feedback. Better to state for the record what is not > > being looked at and why, than let people work on and open the same > > JIRAs repeatedly. > > well stated! > > > > I have also found in the past that a culture of tolerating eternal > > JIRAs led people to file JIRAs in order to forget about a problem -- > > it's in JIRA, and it's "in progress", so it feels like someone else is > > going to fix it later and so it can be forgotten now. > > there's some value in these now-i-can-forget jira, though i'm not > personally a fan. it can be good to keep them around and reachable by > search, but they should be clearly marked as no/not-yet or something > similar. > > > > For what it's worth, I think these project and culture mechanics are > > so important and it's my #1 concern for Spark at this stage. This > > challenge exists so much more here, exactly because there is so much > > potential. I'd love to help by trying to identify and close stale > > JIRAs but am afraid that tagging them is just adding to the heap of > > work. > > +1 concern and potential! > > > best, > > > matt > > --------------------------------------------------------------------- > 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
