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 < [email protected]> 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 >
