+1 on using JIRA workflows to manage the backlog, and +9000 on having decent descriptions for all JIRA issues.
On Tue, Jul 29, 2014 at 7:48 PM, Sean Owen <so...@cloudera.com> wrote: > How about using a JIRA status like "Documentation Required" to mean > "burden's on you to elaborate with a motivation and/or PR". This could > both prompt people to do so, and also let one see when a JIRA has been > waiting on the reporter for months, rather than simply never been > looked at, and should thus time out and be closed. Both of these would > probably help the JIRA backlog. > > On Wed, Jul 30, 2014 at 12:34 AM, Mark Hamstra <m...@clearstorydata.com> > wrote: > > Of late, I've been coming across quite a few pull requests and associated > > JIRA issues that contain nothing indicating their purpose beyond a pretty > > minimal description of what the pull request does. On the pull request > > itself, a reference to the corresponding JIRA in the title combined with > a > > description that gives us a sketch of what the PR does is fine, but if > > there is no description in at least the JIRA of *why* you think some > change > > to Spark would be good, then it often makes getting started on code > reviews > > a little harder for those of us doing the reviews. So, I'm requesting > that > > if you are submitting a JIRA or pull request for something that isn't > > obviously a bug or bug fix, you please include some sort of motivation in > > at least the JIRA body so that the reviewers can more easily get through > > the head-scratching phase of trying to figure out why Spark might be > > improved by merging a pull request. >
