I do see value in having the review PR along with the discussion in the mailing list/jira.
It shows the commitment of the Author to the idea and to the project. There is some truth in what Linus Torvalds says https://lkml.org/lkml/2000/8/25/132 Thanks On Mon, Jan 16, 2017 at 8:11 AM Amol Kekre <a...@datatorrent.com> wrote: > I do see folks discussing issues for most part now. For me this does not > look like an issue that is hurting Apex community. I do however want to > discuss cases where code gets blocked and get spilled into larger context. > As a culture and a process, we have a very high overhead that deters > contributions. > > Thks > Amol > > > On Sun, Jan 15, 2017 at 8:50 PM, Pramod Immaneni <pra...@datatorrent.com> > wrote: > > > Yes, it will be good to have these points added to the contributor > > guidelines but I also see for the most part folks do bring up issues for > > discussion, try to address concerns and come to a consensus and in > > generally participate in the community. I also think we should have some > > latitude in the process when it comes to bug fixes that are contained and > > don't spill into re-design of components otherwise, the overhead will > deter > > contributions especially from folks who are new to the project and want > to > > start contributing by fixing low hanging bugs. > > > > Thanks > > > > On Sun, Jan 15, 2017 at 7:50 PM, Thomas Weise <t...@apache.org> wrote: > > > > > Hi, > > > > > > I want to propose additions to the contributor guidelines that place > > > stronger emphasis on open collaboration and the early part of the > > > contribution process. > > > > > > Specifically, I would like to suggest that *thought process* and > *design > > > discussion* are more important than the final code produced. It is > > > necessary to develop the community and invest in the future of the > > project. > > > > > > I start this discussion based on observation over time. I have seen > cases > > > (non trivial changes) where code and JIRAs appear at the same time, > where > > > the big picture is discussed after the PR is already open, or where > > > information that would be valuable to other contributors or users isn't > > on > > > record. > > > > > > Let's consider a non-trivial change or a feature. It would normally > start > > > with engagement on the mailing list to ensure time is well spent and > the > > > proposal is welcomed by the community, does not conflict with other > > > initiatives etc. > > > > > > Once that is cleared, we would want to think about design, the how in > the > > > larger picture. In many cases that would involve discussion, questions, > > > suggestions, consensus building towards agreed approach. Or maybe it is > > > done through prototyping. In any case, before a PR is raised, it will > be > > > good to have as prerequisite that *thought process and approach have > been > > > documented*. I would prefer to see that on the JIRA, what do others > > think? > > > > > > Benefits: > > > > > > * Contributor does not waste time and there is no frustration due to a > PR > > > being turned down for reasons that could be avoided with upfront > > > communication. > > > > > > * Contributor benefits from suggestions, questions, guidance of those > > with > > > in depth knowledge of particular areas. > > > > > > * Other community members have an opportunity to learn from discussion, > > the > > > knowledge base broadens. > > > > > > * Information gets indexed, user later looking at JIRAs will find > > valuable > > > information on how certain problems were solved that they would never > > > obtain from a PR. > > > > > > The ASF and "Apache Way", a read for the bigger picture with more links > > in > > > it: > > > http://krzysztof-sobkowiak.net/blog/celebrating-17-years- > > > of-the-apache-software-foundation/ > > > > > > Looking forward to feedback and discussion, > > > Thomas > > > > > >
