apex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sandesh Hegde <sand...@datatorrent.com>
Subject Re: Contribution Process before PR
Date Tue, 17 Jan 2017 02:20:15 GMT
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 <amol@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 <pramod@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 <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
> > >
> >
>

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