About a dozen contributors, committers, and PMC members attended this Zoom call.  We discussed the importance of quality code and reviewed some of the recent issues with the 1.8 release.  

Meeting was called by @jdailey. 


Key takeaways from discussion and how we are proceeding:  

  1. As we have a new set of devs onboarded recently, we need to do a better job of communicating norms. We will take this discussion up further and surface ideas.  Right now it is one on one and taking too much time.  
  2. We have code debt / legacy code that needs to be refactored and the first rule of being in a hole is to stop digging.  We need some additional automated tools, for example Aleks proposed "ArchUnit" to enforce architectural norms like stop embedding REST API logic in the service classes (hopefully I captured that detail correctly).  Unfortunately, all too often, the code already there does NOT serve as a good example of how it should be done, so we have to solve for that.  
  3. On the process of submitting Pull Requests (PRs):  The standards are there but we need more people abiding by them. For example, a dev CANNOT simply "check the boxes" on the Pull Request template, you have to do the activities. 
  4. We agree that we can and should reject PRs that fail to abide by the norms and documents we have established.  We should also update those docs. 
  5. For example, Pull Requests that don't have the correct format for the Title fails to link to a Jira ticket and thus creates a lot of additional work for the release manager... which is not cool.  
  6. For example, discussion and design on some PRs is completely lacking - no idea why the Dev thinks the change is a good idea for the project and in some cases no communication at all on Jira tickets or listserv.  This is an "anti-pattern". 
  7. For example, we need to improve the trend toward ideal "componentization" where we stop new contributions that go in the wrong direction. (see again hole digging and ArchUnit). 
  8. The need for QA and good practices around Commits is further highlighted by the new reality of commercial entities moving to an upstream first strategy.  Like many other Apache projects, we are moving to a situation where our code is mission critical and we cannot accept poorly designed and insufficiently documented changes that go into the mainline. 
  9. We thus agreed and submit to the group that undocumented, poorly justified, or designed changes shall be rejected... unless those changes are related to an identified bug.
    1. In the case of a bug that has a solution proposed, the group considered that it was better to have the bug solution than not, and to treat it as an "advanced bug report".  Ideally the person solving the bug also does all of the required activities (i.e. test coverage) but if not, then others agreed that they would step up to ensure that the bug fix gets in. 
    2. In the case of new features and functionality, if there was a lack of design thinking and/or lack of test coverage and/or lack of Jira tickets, then reject. 
  10. Devs shall have a chance to improve their PR and should follow the norms of identifying someone that can help them, they cannot assume that it will happen. 
  11. Devs should move key documentation of the code to those areas that are picked up by the ASCII code generator, rather than embedding all of the design stuff as comments in the classes. 
  12. There is a new test framework in place now that we can use to further enforce code quality.  Those are explained in a post about cucumber, and more details will be shared. There was agreement that we need to be able to have tests that can be run "in parallel" and some discussion about what to do to solve for the challenges there.   


AND... 

  • The group also included those participating in efforts to enhance performance of the system and those contributors and committers involved agreed to work on communicating the high level technical roadmap so that other devs are not caught unaware.  This problem has surfaced on other Apache projects, so we believe it is about improving communication.  
  • Clearly, the prioritization for the project can be influenced by such efforts which can greatly enhance the project, and that may imply that some feature enhancements need to be put on hold until non-functional changes - like implementation of SpringBatch - can be fully integrated. Once communicated, the norm will be to wait until such changes are "in" before accepting other changes as long as the wait is time-bounded.  
  • Additional meetings should be held regularly - perhaps once per month - QA, testing frameworks, new contributions, and paying down code debt are all important and related topics.  


Planned Follow-up Activities: 

  1. Communication on list and post these take aways to fineract wiki (jdailey)
  2. Emphasize on list the importance of communication as a way to ensure working toward a common purpose (jdailey)
  3. Discuss current activities and upcoming roadmap items on the listserv and/or in JIRA tickets (all devs required) 
  4. Explore ArchUnit and propose on the list (Aleks)
  5. Explain Cucumber test framework and check in commits (Aleks) 
  6. Schedule next QA meeting (jdailey)