Updates to code review guidelines : pull request size limits

[Vishwas Babu <vi...@confluxtechnologies.com>]

Hi All,

The PMC has recently updated the code review guidelines at
https://cwiki.apache.org/confluence/display/FINERACT/Code+Review+Guide with
details of pull request size limits. Please let us know if you have any
concerns regarding the same.

Regards,
Vishwas

Re: Updates to code review guidelines : pull request size limits

[James Dailey <ja...@gmail.com>]

Hi All - Good policy change and process clarification.  +1

For transparency and to bump up this discussion, the size limit entry says:
This project does not accept "code dumps" - i.e. massive huge Pull Requests
of major new features consisting of thousands of lines of new code,
typically developed in "downstream" closed source munged into a single PR,
because such contributions are typically simply impossible to code review
realistically. Instead, please engage in the usual open source way of
proposing small incremental changes leading up to bigger new features.

For my part, I commented previously that it would be better to get
contributions than not to get contributions. The problem with permitting
off-list development is that it is unsustainable. Code dumps lead to
projects that don't have the necessary social cohesion to advance their
vision. As a matter of policy, *we should not accept off-list dev.*  Big
code dumps developed off-list greatly compound that mistake.

The implication of this for those individuals that have significantly
forked the MifosX code, and then the fineract1.x and fineract-cn code bases
- and we know you are out there - is to identify the key small incremental
improvement that they want to see in the core project. It is almost
certainly up to these individual contributors to dive back into the project
and find out what they've missed by not being part of the dev on-list, but
they should also note what they can contribute. That is, fineract should
benefit from the real world experience of those implementing the system in
the real world, and not merely those working in demos and academic
environments.  Secondly and even more important, those individuals should
see the benefit of seeing their key changes in the system make it into the
core release.  That is the essence of the virtuous cycle.  Not purely
charitable contribution but enlightened self interest. (This is not a
critique of the open source as sharing culture and freedom of speech.)

Beyond this, and I don't think this is a slippery slope, it would be
advantageous for individuals to be able to compare the various forks that
are out there and to identify common areas of enhancement and bug
resolution and then to borrow, when possible, those solutions and code
enhancements... again, onlist and incrementally introduced. I think all
projects that have forked the code should be transparent about what they
have done in general (and so make their git repos open for inspection) and
to then suggest certain enhancement priorities for the good of their long
term business models. A key point of the license is to allow competitive
use of the code, but to also have a common core that is jointly and
communally maintained.

No to off-list Dev
Yes to transparency
No to massive "code dumps"
Yes to sustainable projects

Thanks for reading.
@jdailey67

On Fri, Mar 22, 2019 at 2:49 PM Vishwas Babu <
vishwas@confluxtechnologies.com> wrote:

> Hi All,
>
> The PMC has recently updated the code review guidelines at
> https://cwiki.apache.org/confluence/display/FINERACT/Code+Review+Guide
> with
> details of pull request size limits. Please let us know if you have any
> concerns regarding the same.
>
> Regards,
> Vishwas
>