We should set up the concepts of CORE and COMMUNITY adaptors.
This is mostly a marketing/branding exercise.
Core adaptors are very much owned by us and are used by multiple users in production. For a core adaptor we expect a reasonable standard of unit testing (increasing our confidence that a "fix" won't break anything"; excellent levels of documentation; modern development practices internally (ie, expanding references properly, using new http helpers); a clean , consistent and generalised API (no functions designed against a single implementation); and better adherence to semver.
As a rule of thumb, we'd expect an outside contributor with basic knowledge of openfn to be able to come in and implement a workflow against that adaptor with little to no support from our core contribution team.
Should there be something about magic functions in there too? It's too early I think,
A Community adaptor is basically any non-core adaptor. It indicates that it was contributed or maintained by an external party, or is a legacy adaptor not brought up to speed yet, or only has a minimal compliance to an adaptor (a thin http wrapper, for example). Community adaptors are likely to have had less development time and are more likely to have experimental, untested or highly bespoke functions.
There is some sort of process for "certifying" an adaptor as Core. This should not be strict, it's probably a vague assessment of quality by me plus some kind of "this is actively used" mention from Implementation or Product.
Ideas of how we can implement/sell/explain this:
Have a CORE badge in the adaptor docs page somewhere. Perhaps on the logo too?
Have some kind of CORE indicator in the adaptor package itself
A list somewhere might activate stricter automated tests in CI
Maybe a core adaptor requires a PR from a core contributor, but a community adaptor can be merged by anyone
This issue is incomplete - just a brain dump
We should set up the concepts of CORE and COMMUNITY adaptors.
This is mostly a marketing/branding exercise.
Core adaptors are very much owned by us and are used by multiple users in production. For a core adaptor we expect a reasonable standard of unit testing (increasing our confidence that a "fix" won't break anything"; excellent levels of documentation; modern development practices internally (ie, expanding references properly, using new http helpers); a clean , consistent and generalised API (no functions designed against a single implementation); and better adherence to semver.
As a rule of thumb, we'd expect an outside contributor with basic knowledge of openfn to be able to come in and implement a workflow against that adaptor with little to no support from our core contribution team.
Should there be something about magic functions in there too? It's too early I think,
A Community adaptor is basically any non-core adaptor. It indicates that it was contributed or maintained by an external party, or is a legacy adaptor not brought up to speed yet, or only has a minimal compliance to an adaptor (a thin http wrapper, for example). Community adaptors are likely to have had less development time and are more likely to have experimental, untested or highly bespoke functions.
There is some sort of process for "certifying" an adaptor as Core. This should not be strict, it's probably a vague assessment of quality by me plus some kind of "this is actively used" mention from Implementation or Product.
Ideas of how we can implement/sell/explain this: