On 08/26/2014 04:57 AM, Sean Owen wrote:
On Tue, Aug 26, 2014 at 7:02 AM, Patrick Wendell <pwend...@gmail.com> wrote:
Most other ASF projects I know just ignore these patches. I'd prefer if we
Agree, this drives me crazy. It kills part of JIRA's usefulness. Spark
is blessed/cursed with incredible inbound load, but would love to
still see the project get this right-er than, say, Hadoop.
totally agree, this applies to patches as well as jiras. i'll add that
projects who let things simply linger are missing an opportunity to
engage their community.
spark should capitalize on its momentum to build a smoothly running
community (vs not and accept an unbounded backlog as inevitable).
The more important thing, maybe, is how we want to deal with this
culturally. And I think we need to do a better job of making sure no pull
requests go unattended (i.e. waiting for committer feedback). If patches go
stale, it should be because the user hasn't responded, not us.
Stale JIRAs are a symptom, not a problem per se. I also want to see
the backlog cleared, but automatically closing doesn't help, if the
problem is too many JIRAs and not enough committer-hours to look at
them. Some noise gets closed, but some easy or important fixes may
disappear as well.
engagement in the community really needs to go both ways. it's
reasonable for PRs that stop merging or have open comments that need
resolution by the PRer to be loudly timed out. a similar thing goes for
jiras, if there's a request for more information to resolve a bug and
that information does not appear, half of the communication is gone and
a loud time out is reasonable.
easy and important are in the eyes of the beholder. timeouts can go both
ways. a jira or pr that has been around for a period of time (say 1/3
the to-close timeout) should bump up for evaluation, hopefully resulting
in few "easy" or "important" issues falling through the cracks.
fyi, i'm periodically going through the pyspark jiras, trying to
reproduce issues, coalesce duplicates and ask for details. i've not been
given any sort of permission to do this, i don't have any special
position in the community to do this - in a well functioning community
everyone should feel free to jump in and help.
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.
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
