Decide and document process of accepting community contributions

[pedrosousabarreto]

Request:

To accept contributions that are not part of the core (or core dependencies) and/or will be maintained by the community (not the core team) we need to define:

2. A process for accepting these kinds of projects into the Mojaloop organization and what the implications of that are (who maintains them etc)

Decision(s):

• [ ] Actual decision made as a result of discussion

Follow-up:

• [ ] Alternative actions

Dependencies:

• [ ] If Applicable

Accountability:

• Owner: @adrianhopebailie

Notes:

This discussion may need to include input from the TGB

[mjbrichards]

Following the DA discussion 2022-02-14, the following points were agreed:

• Contributions should align with our Community Standards
• Where a submitting group wants an exception to the standard, it should request that from the DA.
• If the DA grants an exception, the exception and the reasoning should be documented and stored in the repository.
• Otherwise, it is the responsibility of the submitting group to revise its contribution to meet the standards.
• Code must be well tested, and it must be possible for a third party to test it.
• Code must have the prerequisite testing automation common to any modern open source community. Martin Fowler’s short blog post about the Testing Pyramid is a good reference here.
• Documentation criteria: the code must be well documented enough that a new contributor could come and develop a new feature or fix a bug with little to no input from the original authors of the codebase. Criteria for acceptance

Question: does the Community Standards guide need to be extended? If so, how? - Process:

• Submitting groups (or other parties) should request extensions to the standards, the DA should make a judgment.
• The requesting group should update the standards as agreed.

Question: are the standards currently in a usable state, or do they need more?

• PSB: typescript needs more…
• MdB: Feedback from newly onboarded developers?
• Need to foreground requirement for use of community standards on the site
• PSB: testing is fundamentally important, we should emphasise this more…

[elnyry-sam-k]

Needs to be discussed in a separate session and outcomes documented.

[pedrosousabarreto]

Looks like we're only missing:

• Define what is the documentation standard and/or minimum
• Describe the minimum tests that have to exist, pass and code coverage percentage (these exist already)
• Clarify the coding standards, which are mandatory, how to request new standards, etc
• Clarify what are the issues that newly on-boarded developers identify, these might help tune the process

[PaulGregoryBaker]

There is already a process in our standards for "Adopting Open Source Contributions into Mojaloop"

As defined here.

[mdebarros]

Link to contributors form provided by @simeonoriko : https://docs.google.com/forms/d/e/1FAIpQLSfTvCmGBkYwfjnx589doxbc7GaJT8fU3UDpKRLxvd16EuFhUw/viewform

[mdebarros]

Similiar references provided during today's call by @dpcMomo:

• https://www.apache.org/foundation/getinvolved.html
• https://infra.apache.org/contributors

[pedrosousabarreto]

Adding two points to list of missing things above...

We need to clarify the difference between:

• Contribution: fix, enhancement, new module/lib, etc
• Incubation: complete new software product with it's own use cases, different architecture, design principles or software stack. (see the link that Istvan provided to apache's incubator cookbook here)

We also need to decide the support model:

• Will a new workstream be established to support it?
• Will this be supported by the core team?
• Will the contributor's team support the contributed software?

For this support model discussion we can assume the examples of security related dependency updates or license related, which are forced.

[MichaelJBRichards]

My notes from yesterday's meeting:

• Should we compare with other standards (e.g. Apigee)? IM to look and report back
• Typescript: Standard now supports Typescript. MB: we should use it for everything… JF Example of Prettier+ESLint… For JS use this file, for TS use that file… We do not allow commit unless linting has been run.
• Are we accepting code in other languages? For third party components, yes. MB: these are the recommended languages. We may accept contributions in other languages, but only with DA approval. What should be on the list? Javascript, typescript. Preference is TypeScript
• API endpoints should support OpenApi 3.0.1
• Adopting Open Source Contributions into Mojaloop…:
  • MB: in incubation: how do you create a private repo in Mojaloop? Should it be a form, a Slack channel, what? SO: We have a form for contribution here: https://docs.google.com/forms/d/e/1FAIpQLSfTvCmGBkYwfjnx589doxbc7GaJT8fU3UDpKRLxvd16EuFhUw/viewform. Payment manager did this, and is the only one to date.
  • What is the minimum documentation and the minimum tests (PSB): this is not specific.
  • PSB: how are we going to take care of code?
• IM: If we are talking about complete new softwares, the Apache way of doing it via the incubator program: https://incubator.apache.org/; https://incubator.apache.org/cookbook/;
  • https://www.apache.org/foundation/getinvolved.html
  • https://infra.apache.org/contributors

[mdebarros]

Link to Mojaloop's Official Contributor's Guide: https://docs.mojaloop.io/community/contributing/contributors-guide.html Link to Mojaloop's Official Adopting Open Source Contributions into Mojaloop: https://docs.mojaloop.io/community/standards/guide.html#adopting-open-source-contributions-into-mojaloop

[bushjames]

@simeonoriko has a document in progress from community council specifying MLF requirements. This will be published soon. Updates and cross references will be included in a future main docs website update by @bushjames .