You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@fineract.apache.org by James Dailey <ja...@gmail.com> on 2022/09/07 19:16:01 UTC

Community over code

hi Devs -

At Apache, there is a saying "Community over code".  This is a maxim
intended to signal that it is important to get along and work
together, rather than at cross purposes.

For every implementing company (system integrators, software
provider), fintech, or financial institution out there using Fineract,
and for every team trying to make changes to fit their specific needs,
it is important that we - as a community here - define our intentions
and hold each other accountable.

Right now, we have teams of people designing and working on enhancing
some core underlying infrastructure of Fineract.  This could run up
against devs trying to add a single point of functionality, unaware
how a code change can impact weeks of design and work.

So, point number one:  "Communicate on the list and in Jira Tickets
what you are intending to do".   If you are not communicating then it
is expected behavior to reject your code changes even if you are a
committer.  Especially if you are not in touch with other devs, it is
important that you provide more context for your proposed changes.

Number two:  I've recently convened a quality assurance group and have
published some decisions and guidance to the wiki. Thus, another
principle is "More quality and better maintainable code".

Number three:  Especially if you are running a system in production,
where risk management is important, then you have to be aware of
upcoming code improvements and confident that when you get the latest
release that it will be stable.
"Stable code often comes from refactoring, not adding new stuff"
and
"More and better test coverage". Alexs and a number of others are
working on the Cucumber framework and will be introducing how that
will enhance the test coverage and how to contribute to that.

Number four: If you are running a system in production, especially in
a high availability environment and with scale, then you need both
scalability and performance.  Thus, a third principle is "Scale and
performance must be part of the code changes".

I look forward to a discussion.

@jdailey