On Aug 31, 2012, at 4:19 PM, Travis Crawford wrote: > Thanks for starting this discussion Alan! > > Something we might try is having "patch available" issues mailed to > the list each day, and working towards managing the list to 0, by > either committing or bouncing back to "open" if it need more work. I > personally subscribe to that jira query and find it quite useful. +1, being reminded every day what needs looked at should help us.
> > Maybe this is obvious to those with more open source experience, but > I'm learning each "external" patch bears some amount of risk, since > how it fits into the contributors overall goals may not have been > communicated well. We could use "epic stories" or design docs to > communicate high-level goals so the purpose of external patches is > more clear. For example, I'm super focused on thrift support which > explains a lot of our patches, but wouldn't be clear to a reviewer > looking at them in isolation. This could help reduce risk of accepting > patches since it would be clear how they fit into bigger-picture > goals. +1. I think there's two important things here. One communicating clearly what you're doing, and two where you communicate that. For anything beyond a simple bug fix it's very helpful for reviewers if you say what use case you're trying to solve, what changes you will make, how those changes will fit in with the current system, and how you plan to test your changes. For small features this can all be done in the JIRA for the feature. For bigger features or things that will span several JIRAs one could use an umbrella JIRA or wiki. I think we should add this to the How To Contribute doc on wiki so that we can point contributors to it. Alan. > > Just tossing some ideas out, curious what others think. > > --Travis > > On Aug 31, 2012, at 4:04 PM, Alan Gates <[email protected]> wrote: > >> It is pretty clear that we, the HCatalog committers, are not doing a good >> enough job of reviewing patches in a timely manner. Many committers or >> other contributors are posting patches only to have them wait for a couple >> of weeks before someone reviews them. Then when any requested changes have >> been made it is another couple of weeks before a +1 and the code can be >> checked in. This is bad for a number of reasons. It makes it hard for >> committers to move forward with what they are working on. It does not >> encourage others to join our community, as we appear to be spurning their >> contributions. And it means that users do not get access to bug fixes and >> new features as soon as they could. >> >> We as a community need to figure out how we want to resolve this. >> Suggestions? >> >> Alan.
