Bringing a discussion to dev@. I think the general questions on the table are:
- Should more changes be rejected? What are the pros/cons of that?
- If no, how do you think about the very large backlog of PRs and JIRAs?
- What should be rejected and why?
- How much support is there for proactively cleaning house now? What
would you close and why?
- What steps can be taken to prevent people from wasting time on JIRAs
/ PRs that will be rejected?
- What if anything does this tell us about the patterns of project
planning to date and what can we learn?
This overlaps with other discussion on SPARK-6889 but per Nicholas
wanted to surface this
---------- Forwarded message ----------
From: Nicholas Chammas (JIRA) <j...@apache.org>
Date: Tue, Apr 14, 2015 at 3:38 PM
Subject: [jira] [Commented] (SPARK-6889) Streamline contribution
process with update to Contribution wiki, JIRA rules
To: iss...@spark.apache.org
Nicholas Chammas commented on SPARK-6889:
-----------------------------------------
{quote}
I also agree that most projects don't say "no" enough and it's
actually bad for everyone. Yes, one goal was to also set more
expectation that lots of changes are rejected. If there is widespread
agreement, I'd also like firmer language in the guide. As you say it
is also a matter of taste and culture, but, I'd personally favor a lot
more "no".
{quote}
Regarding this point about culture, should we have some kind of
discussion on the dev list to nudge people in the right direction?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org
For additional commands, e-mail: dev-h...@spark.apache.org
