[ 
https://issues.apache.org/jira/browse/SPARK-6889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14495997#comment-14495997
 ] 

Sean Owen commented on SPARK-6889:
----------------------------------

[~sree_at_ch...@yahoo.com] I think you're arguing to host everything on, say, 
Github and not bother with an Apache-based git, site or wiki. I like the Github 
all-in-one model, but the site situation here isn't a problem in practice and 
wouldn't lobby to change that. Bluntly, this project has the opposite problem: 
it's too easy to make a contribution, not too hard, but the contribution is 
often misdirected. I think too much time is being spent trying to process and 
shepherd these, not too little.

[~josephkb] I added a proposed TL;DR for CONTRIBUTING.MD to the document online.

[~brkyvz] In reply to your comment on the mailing list, yes I've added a new 
short section advocating spark-packages.org as something to consider before 
proposing a change to Spark.

[~imranr] This also sort of addresses your comment. I'm going to strengthen the 
language a little bit to emphasize the obvious: deep fixes are better than 
band-aids, fixes are better than just bug reports, bug reports with a 
reproduction is better than without, and bug reports without a reproduction 
really aren't helpful. And maybe that feature requests without intent to 
implement the feature are not viewed as helpful. And I'd like to add a more 
explicit section about "what to do if your PR isn't being merged", with a 
stronger suggestion that contributors help by voluntarily withdrawing changes 
that have met with objections or no clear enthusiasm.

All: as an experiment, I'd also like to try pushing back more on pull requests 
and JIRAs for a short time, as you've seen me start to do. If it's apparent 
that it feels too aggressive or trigger happy, then at least we'll discover 
where the balance seems to be. See how it strikes you!

> 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, faq.html.patch
>
>
> 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

Reply via email to