search

mojaloop / design-authority-project

This is the Issue and Decision Log for tracking mojaloop and related Designs
1 stars 2 forks source link

Standardisation on Code and Library Usage Standards #36

Closed NicoDuvenage closed 4 years ago

NicoDuvenage commented 4 years ago

Request:

  1. We should develop two guides: (1) A Mojaloop OSS code style guide, and (2) A Mojaloop OSS Framework and tool recommendation guide 1.1 The style guide will dictate: code style, directory structure, and include prettier and editor config files [please add to this list as you see fit] 1.2 The framework and tool recommendation guide will contain strong recommendations about frameworks and tools (such as Hapi for web servers, Logging tools, RC for configs, Docker for containerization)

  2. We need to establish a framework for accepting adoptions. 2.1 This means clearly outlining in the above guides what is completely unacceptable and will need to be refactored before being brought into the OSS Codebase, and what is considered ‘ok for now’ and we are happy to use, with the knowledge that some important component of this adoption will need major refactoring. 2.1.1 We could look at the new mojaloop-simulator as an example: We could decide that the current directory structure is not ok and we need to have the package.json file in the root directory, but say that the web framework used in this library is ok for now, but know that we may want to refactor it to use Hapi in the future if we want to bring in more features from other parts of the Mojaloop codebase 2.2 Sam suggested we can bring code into repos with some ‘pending’ tag or state, to facilitate such a workflow 2.3 We also don’t want to block new technologies that could be beneficial from entering the codebase on the basis that we already use some other tool. So we need some method for OSS contributors to outline a new technology or tool, and make a case for as to why it should be included in the codebase, and a method for updating the standards, and refactoring legacy code if needed.

  3. We need to walk a careful line between rejecting contributions and just adopting anything that doesn’t explicitly conform to our standards 3.1 As @adrianhopebailie said, we likely want a ‘deeper’ codebase with less contributions, strict standards with less maintenance burden than have a ‘wide’ code base with many contributions that are hard to maintain (edited) 3.2 We want to avoid hard forks as much as possible (maybe even at all costs? - feel free to add your opinions).

Artifacts:

Decision(s):

Follow-up:

Dependencies:

Accountability:

Notes:

lewisdaly commented 4 years ago

This is a Draft PR which outlines most of the changes discussed:

https://github.com/mojaloop/documentation/pull/116