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 > > >
