[
https://issues.apache.org/jira/browse/SPARK-6889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14496481#comment-14496481
]
Sean Owen commented on SPARK-6889:
----------------------------------
We can take away old docs that encourage people to head straight for a PR /
JIRA; we can make that info harder to find without first reading through the
prerequisites. We can put the info more prominently in the common paths (i.e.
the default description of a JIRA?) and not feel bad about closing JIRAs that
aren't suitable straight away with an invitation to try again once the items in
the wiki have been addressed. Yes, not just a thought exercise.
And of course there are a few JIRA-related changes that can help enforce a few
of these requirements.
Current proposed text also encourages contributors to help by withdrawing pull
requests that seem to have been reviewed, but, not positively received.
You're right that this is only a piece of the overall issue, and "enforcement"
is too. Although I do believe some house-cleaning and change of disposition is
in order (I'm experimenting with that now -- just try it!) I wanted to first
focus on avoiding having to close things in the first place, since that's a
suboptimal outcome. This is a part, and so is making JIRA a more reliable
source of information about what's in/out of scope.
> 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: [email protected]
For additional commands, e-mail: [email protected]
