Re: Proposal for new coding standard
On Sun, Apr 26, 2020 at 12:51 AM Nikhil Pawar wrote: > Mike, > > I have added this to README.md under governance section. > I was trying to add it to Confluence but it looks like I don't have > access, I thought committers have default access to project's wiki and code. > yeah you totally should have. I have just checked https://cwiki.apache.org/confluence/spaces/spacepermissions.action?key=FINERACT and nikhilpawar (I'm assuming that's the account you are using, unless you created several?) does seem to have e.g. Pages > Add permission. I'm not sure what's missing. Can I suggest that you create a JIRA Ticket in the INFRA component for the Confluence maintainers at the ASF to assist you? You can reference this email thread with a link. > https://github.com/apache/fineract/pull/781 > Thank You - merged! On Tue, Apr 21, 2020 at 4:28 PM Michael Vorburger wrote: > >> Nikhil, +1 this makes sense. Perhaps you'd like to add this to >> https://cwiki.apache.org/confluence/display/FINERACT/Pull+Request+Size+Limit >> or https://github.com/apache/fineract/#governance-and-policies ? >> >> ___ >> Michael Vorburger >> http://www.vorburger.ch >> >> >> On Sun, Apr 19, 2020 at 11:48 PM Nikhil Pawar wrote: >> >>> Devs, >>> >>> While I was going through a PR- it occurred to me that we should adapt >>> this new coding standard which will largely simplify the life of the >>> reviewer. >>> >>> Whenever we are writing a new feature and if involves refactoring, we >>> should separate Refactored code with a new Feature code. >>> Such differentiation helps reviewer to examine refactoring with the >>> lens of whether this change has broken existing behavior ( may be just look >>> unit test cases) and breeze through. >>> >>> And while evaluating new feature commit just examine whether the new >>> feature really achieves the goal of new requirement without having to worry >>> about it breaking existing behavior. >>> >>> Of course it is difficult to estimate before hand whether the change >>> will require refactoring or not, but once we know it , we should segregate >>> the changes. >>> >>> If interested there is a nice talk on refactoring by Martin Fowler: >>> https://youtu.be/vqEg37e4Mkw >>> >>> Regards, >>> Nikhil >>> >>
Re: Proposal for new coding standard
Mike, I have added this to README.md under governance section. I was trying to add it to Confluence but it looks like I don't have access, I thought committers have default access to project's wiki and code. https://github.com/apache/fineract/pull/781 On Tue, Apr 21, 2020 at 4:28 PM Michael Vorburger wrote: > Nikhil, +1 this makes sense. Perhaps you'd like to add this to > https://cwiki.apache.org/confluence/display/FINERACT/Pull+Request+Size+Limit > or https://github.com/apache/fineract/#governance-and-policies ? > > ___ > Michael Vorburger > http://www.vorburger.ch > > > On Sun, Apr 19, 2020 at 11:48 PM Nikhil Pawar wrote: > >> Devs, >> >> While I was going through a PR- it occurred to me that we should adapt >> this new coding standard which will largely simplify the life of the >> reviewer. >> >> Whenever we are writing a new feature and if involves refactoring, we >> should separate Refactored code with a new Feature code. >> Such differentiation helps reviewer to examine refactoring with the lens >> of whether this change has broken existing behavior ( may be just look unit >> test cases) and breeze through. >> >> And while evaluating new feature commit just examine whether the new >> feature really achieves the goal of new requirement without having to worry >> about it breaking existing behavior. >> >> Of course it is difficult to estimate before hand whether the change will >> require refactoring or not, but once we know it , we should segregate the >> changes. >> >> If interested there is a nice talk on refactoring by Martin Fowler: >> https://youtu.be/vqEg37e4Mkw >> >> Regards, >> Nikhil >> >
Re: Proposal for new coding standard
Nikhil, +1 this makes sense. Perhaps you'd like to add this to https://cwiki.apache.org/confluence/display/FINERACT/Pull+Request+Size+Limit or https://github.com/apache/fineract/#governance-and-policies ? ___ Michael Vorburger http://www.vorburger.ch On Sun, Apr 19, 2020 at 11:48 PM Nikhil Pawar wrote: > Devs, > > While I was going through a PR- it occurred to me that we should adapt > this new coding standard which will largely simplify the life of the > reviewer. > > Whenever we are writing a new feature and if involves refactoring, we > should separate Refactored code with a new Feature code. > Such differentiation helps reviewer to examine refactoring with the lens > of whether this change has broken existing behavior ( may be just look unit > test cases) and breeze through. > > And while evaluating new feature commit just examine whether the new > feature really achieves the goal of new requirement without having to worry > about it breaking existing behavior. > > Of course it is difficult to estimate before hand whether the change will > require refactoring or not, but once we know it , we should segregate the > changes. > > If interested there is a nice talk on refactoring by Martin Fowler: > https://youtu.be/vqEg37e4Mkw > > Regards, > Nikhil >
