All -
On Wed, Aug 31st, we held a zoom call and had about a dozen people join for
this discussion. I am reporting back to the list per our community norms.
After 72 hrs I will document this on the Wiki to capture our agreement.
Key takeaways from discussion and how we are proceeding:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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".
- 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).
- 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.
- 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.
- 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.
- 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.
- 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.
-
- 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.
- 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.
I want to thank @Aleks in particular for his contributions to this topic.
Thanks,
@[email protected] <[email protected]>
Fineract
