apex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Munagala Ramanath <...@datatorrent.com>
Subject Re: Contribution Process before PR
Date Mon, 16 Jan 2017 04:28:53 GMT
Yes, I think an initial discussion that includes some or all of the
would be invaluable both for feature implementations and for bug fixes:
1. Discussion of current implementation and how/why it fails to meet
current need.
2. Possible approaches and tradeoffs (if any) for each.
3. Recommended best approach if author has reached such a conclusion.

However, some contributors may want to throw in a prototype implementation
as a
PR as part of the discussion since code has a clarity and precision that,
ultimately, cannot be matched by natural language. We should allow and even
encourage this since it helps, in many cases, to avoid a long chain of Q&A.
It also helps others to try out working code to make their own assessment
of its strengths and weaknesses. Additionally, it helps contributors whose
English may not be as strong as their coding skills, to participate in the

In such cases, it should be clearly understood that the PR is potentially
throwaway code, intended to further the discussion and not necessarily
intended to be merged.


On Mon, Jan 16, 2017 at 9:20 AM, Thomas Weise <thw@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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message