[
https://issues.apache.org/jira/browse/SPARK-6889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14493394#comment-14493394
]
Nicholas Chammas commented on SPARK-6889:
-----------------------------------------
Thanks for continuing to work on improving the contribution process, [~srowen].
The changes you are proposing look great to me (especially regarding JIRA
workflow and permissions), and I wholeheartedly agree with your conclusion
about directing non-committer attention and energy appropriately:
{quote}
I first want to figure out how to better direct the enthusiasm of new
contributors instead, to make less wasted effort and thus less work all around.
{quote}
I'd like to add a few suggestions for everyone's consideration.
\\
1. Our contribution guide will work better when a) it is more visible and b)
specific parts of it can be referenced easily.
a) Visibility: Maybe it's just me, but to me the wiki feels like a dusty
warehouse in a quiet part of town. People just don't go there often. The
high-traffic area we already have to present contribution guidelines is [in the
repo itself|https://github.com/apache/spark/blob/master/CONTRIBUTING.md]. I
would favor moving the contributing guide wholesale there and reducing the wiki
version to a link.
b) Easy References: Our contributing guide is already quite lengthy. For the
newcomer it will definitely be onerous to read through. This is unavoidable for
the time being, but it does mean that people will continue to (as they have
been) contribute without reading the whole guide or reading the guide at all.
This means we'll want to direct people to the appropriate parts of the guide
when relevant. So I think being able to link to specific sections is very
important.
\\
2. We need to give more importance, culturally, to the process of turning down
or redirecting work that does not fit Spark's current roadmap. And that also
needs to be reflected in our contribution guide.
Not having this culture, as far as I can tell, is the #2 reason we have so many
open, stale PRs, which amount to wasted work and unhappy contributors. (The #1
reason is that there is simply not enough committer time to go around).
This is addressed in the proposed contributing guide under the sub-section
"Choosing What to Contribute", but I think it needs to be much more prominent
and easily reference-able. To me, this is much more important than describing
the mechanics of using JIRA/GitHub (though, of course, that is still necessary).
To provide a motivating example, take a look at the [contributing guide for the
Phabricator
project|https://secure.phabricator.com/book/phabcontrib/article/contributing_code/].
There is a large section dedicated to explaining why a patch might be
rejected. Furthermore, the guide gives top prominence to the importance of
coordinating first before contributing non-trivial changes.
[Phabricator - Contributing
Code|https://secure.phabricator.com/book/phabcontrib/article/contributing_code/]:
{quote}
h3. Coordinate First
...
h3. Rejecting Patches
If you send us a patch without coordinating it with us first, it will probably
be immediately rejected, or sit in limbo for a long time and eventually be
rejected. The reasons we do this vary from patch to patch, but some of the most
common reasons are:
...
{quote}
More importantly, the Phabricator core devs back up this guide with effective
action.
For example, take a look at [this
exchange|https://secure.phabricator.com/D9724#79498] between Evan Priestley
(one of the project's leads) and a contributor, where Evan gives a firm but
appropriate "no" to a proposed patch.
[Phabricator - Allow searching pholio mocks by
project|https://secure.phabricator.com/D9724#79498]:
{quote}
Phabricator moves pretty quickly, especially given how small the core team is.
A big part of that is being aggressive about avoiding and reducing technical
debt. This patch -- and patches like it -- add technical debt by solving a
problem with a planned long-term solution in a short-term way.
The benefit you get from us saying "no" here is that the project as a whole
moves faster.
{quote}
I would love to see more Spark committers doing this on a regular basis.
I'm sure people will at first feel uncomfortable about turning down work
directly because it somehow feels rude, even if that work doesn't fit Spark's
roadmap or is somehow otherwise off. But with the right communication and the
long-term health of the project in mind, we can make it into a good habit that
benefits both committers and contributors.
> Streamline contribution process with update to Contribution wiki, JIRA rules
> ----------------------------------------------------------------------------
>
> Key: SPARK-6889
> URL: https://issues.apache.org/jira/browse/SPARK-6889
> Project: Spark
> Issue Type: Improvement
> Components: Documentation
> Reporter: Sean Owen
> Assignee: Sean Owen
> Attachments: ContributingtoSpark.pdf,
> SparkProjectMechanicsChallenges.pdf
>
>
> From about 6 months of intimate experience with the Spark JIRA and the
> reality of the JIRA / PR flow, I've observed some challenges, problems and
> growing pains that have begun to encumber the project mechanics. In the
> attached SparkProjectMechanicsChallenges.pdf document, I've collected these
> observations and a few statistics that summarize much of what I've seen. From
> side conversations with several of you, I think some of these will resonate.
> (Read it first for this to make sense.)
> I'd like to improve just one aspect to start: the contribution process. A lot
> of inbound contribution effort gets misdirected, and can burn a lot of cycles
> for everyone, and that's a barrier to scaling up further and to general
> happiness. I'd like to propose for discussion a change to the wiki pages, and
> a change to some JIRA settings.
> *Wiki*
> - Replace
> https://cwiki.apache.org/confluence/display/SPARK/Contributing+to+Spark with
> proposed text (NewContributingToSpark.pdf)
> - Delete
> https://cwiki.apache.org/confluence/display/SPARK/Reviewing+and+Merging+Patches
> as it is subsumed by the new text
> - Move the "IDE Setup" section to
> https://cwiki.apache.org/confluence/display/SPARK/Useful+Developer+Tools
> - Delete
> https://cwiki.apache.org/confluence/display/SPARK/Jira+Permissions+Scheme as
> it's a bit out of date and not all that useful
> *JIRA*
> Now:
> Start by removing everyone from the 'Developer' role and add them to
> 'Contributor'. Right now Developer has no permission that Contributor
> doesn't. We may reuse Developer later for some level between Committer and
> Contributor.
> Later, with Apache admin assistance:
> - Make Component and Affects Version required for new JIRAs
> - Set default priority to Minor and type to Question for new JIRAs. If
> defaults aren't changed, by default it can't be that important
> - Only let Committers set Target Version and Fix Version
> - Only let Committers set Blocker Priority
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org
For additional commands, e-mail: issues-h...@spark.apache.org
