[ 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