Details
-
Improvement
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
None
-
None
Description
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
Attachments
Attachments
Issue Links
- links to
