...
- Code of Conduct: https://www.edgexfoundry.org/about/code-of-conduct/
- Contributors Guide: https://wikilf-edgexfoundry.edgexfoundryatlassian.orgnet/wiki/display/FA/Contributor%27s+Guide
EdgeX Charter
In addition, all EdgeX contributors must comply with the project’s charter, including the IP policy provisions contained within Section 12 of the charter. You can find the charter here: https://www.edgexfoundry.org/about/project-charter/.
...
- Architectural fit: does the contribution live up to the EdgeX architectural tenets and fit within the existing framework? If it does not the committee may comment for TSC consideration whether they believe the underlying architecture is a superior architecture and one that may need to be explored by the TSC and project overall.
- Quality of the code: does the contribution adhere to good industry and EdgeX required programming practices and standards (see https://wikilf-edgexfoundry.edgexfoundryatlassian.orgnet/wiki/display/FA/Contributor%27s+Guide for the EdgeX contributor guidelines)? Does the contribution actually build and run as is or will it require a lot of additional work be done? Does the contribution and run on Intel and Arm platforms?
- Quality and depth of documentation: is the code adequately commented, is there sufficient documentation to explain what the contribution does, how it works and how to use it (from a novice user point of view)?
- Test coverage: does the code base contain adequate unit tests, integration tests, blackbox test additions, etc.? Additions, via PR may need to be submitted for test repositories (such as the blackbox tests repository) to satisfy this need.
- Performance impact: does the contribution negatively impact the EdgeX footprint, CPU usage, memory usage, start up time, or other performance characteristic? The negative impact is relative, but any significant impact to performance would need to carefully considered.
- DevOps impact: does the contribution require special devOps, continuous integration or deployment aspects of EdgeX. If so, what is the resource requirements to incorporate the contribution into the EdgeX devOps, CI, etc. processes? Does it have Dockerfiles (amd64 and arm64) and other devOps artifacts to incorporate into the EdgeX DevOp environment with little or no changes?
- Long-term maintenance: what are the long-term implications of accepting the contribution on the EdgeX community? Are there sufficient committers, maintainers, contributors that are in the community (or joining the community with the addition) to manage the contribution in the future?
- Roadmap priority: does the contribution fulfill an existing EdgeX roadmap need/item? If it does not, does accepting the contribution meet an anticipated community or user need that makes maintaining the contribution long term a good investment for EdgeX community time?
- Dependency analysis: does the contribution require upstream components, and, if so, are they all under the Apache-2.0 license?
- Does the contribution represent a fork of an upstream project? If so, why is it necessary to fork the upstream project, and do the project leads commit to update the contribution with upstream security patches and bug fixes?
- License requirements: is the contribution done under the Apache-2.0 license, does it contain all the appropriate license files, headers in the source files, attribution files where necessary? Are all the commits properly signed-off?
4b. The ad-hoc committee will review the contribution for general EdgeX use. However, the committee may find the contribution (or a portion of the contribution) would better exist as a project or addition to a vertical working group solution. Therefore, the ad-hoc committee may pass the contribution (or a portion of the contribution) on to the appropriate vertical working group chairperson where the same evaluation would occur, but in light of any EdgeX vertical solution.
Special note for device service contributions: the device service working group chair has documented a review process for how new device services will be examined.
...
The list of repositories associated to the various Working Groups is here: https://wikilf-edgexfoundry.edgexfoundryatlassian.orgnet/wiki/display/FA/Technical+Work+in+the+EdgeX+Foundry+Project#TechnicalWorkintheEdgeXFoundryProject-AppointmentofCommittersandMaintainers
Small code contributions must still comply with the EdgeX charter. In addition, small code contributions should follow the procedure for large code contributions if the answer to any of the following questions is ‘yes’:
...