...
Stage 2 Criteria (from the PLD) | Meets / Needs Improvement / Missing / Not Applicable | Supporting Data (if needed, include links to specific examples) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Development of a growth plan (to include both roadmap of projected feature sets as well as overall community growth/project maturity), to be done in conjunction with their project mentor(s) at the TAC. | We maintain a roadmap for the next 2 years and have a long term backlog that extends beyond that timeframe. The next couple of releases are documented with pages in our Wiki (and you can see past release roadmaps) here: https://wiki.edgexfoundry.org/display/FA/Roadmap. Minor fixes and enhancements are also captured in issues with each repository in Github. Github tags are used to label bugs from enhancement requests and when appropriate are associated with a specific target release (see https://github.com/edgexfoundry/edgex-go/issues for an example). | |||||||||||||||||||||||||||||||||||||||||||||||||||||
Document that it is being used in POCs. | EdgeX is used in countless POCs worldwide. This list is more about production uses.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||
Demonstrate a substantial ongoing flow of commits and merged contributions. | Collected from LF Insights for the project since inception and for the last 1 year
Jim St. Ledger requested a timeline of EdgeX contributor data over the three years or more of the project. Insights provides these statistics for the past 5 years.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||
Demonstrate that the current level of community participation is sufficient to meet the goals outlined in the growth plan. | 8 successful project releases since April 2017 (2 each year). 2nd major release (EdgeX 2.0) released on June 30th 2021 A list of organization having submitted a pull request (in order of the volume of PRs submitted)
| |||||||||||||||||||||||||||||||||||||||||||||||||||||
Demonstrate evidence of, or a plan for, interoperability, compatibility or extension to other LF Edge Projects. Examples may include demonstrating modularity (ability to swap in components between projects). |
With regard to convergence with Fledge, both organizations have provided connectors to each other's system (for importing/exporting data) but no further discussions have taken place around additional convergence or interoperability |
Stage 2 Projects, please skip to Additional Information Requested from All Projects
...
Criteria | Meets / Needs Improvement / Missing / Not Applicable | Supporting Data (if needed, include links to specific examples) |
|---|---|---|
Have a defined governing body of at least 5 or more members (owners and core maintainers), of which no more than 1/3 is affiliated with the same employer. In the case there are 5 governing members, 2 may be from the same employer. | Our current TSC is comprised of members from Intel, Canonical, IOTech, HP, Beechwoods, and VMWare. For names and details see: | |
Have a documented and publicly accessible description of the project's governance, decision-making, and release processes. | Matters of project governance, decision making and process are covered in our project Wiki. The following pages outline our policies. Guidance for how to submit code contributions is defined here: https://wiki.edgexfoundry.org/display/FA/Contributor%27s+Guide and here: https://wiki.edgexfoundry.org/display/FA/Contributor%27s+Process Documentation on how our release process and what gets released is here: https://wiki.edgexfoundry.org/display/FA/Release+Process and some additional information on what is considered a release artifact is defined here: https://docs.edgexfoundry.org/1.2/design/adr/devops/0007-Release-Automation/ | |
Have a healthy number of committers from at least two organizations. A committer is defined as someone with the commit bit; i.e., someone who can accept contributions to some or all of the project. | Work group chairs automatically have committer rights to their work group repositories and nominate others as committers as spelled out in our governance here: https://wiki.edgexfoundry.org/pages/viewpage.action?pageId=21823860#Contributors,Committers&Maintainers-NominationandApprovalofMaintainersandCommitters
| |
Demonstrate evidence of interoperability, compatibility or extension to other LF Edge Projects. Examples may include demonstrating modularity (ability to swap in components between projects). |
| |
Adopt the Foundation Code of Conduct. | For any significant community meeting such as the TSC meetings or meeting where we are inviting outside community to speak or observe are always preceded by the code of conduct and anti-trust policy statements. To date, we have had no unacceptable behavior incidents that the project has been made aware of. EdgeX adheres to, follows and enforces the LF Edge Code of Conduct with out addendum today. | |
Explicitly define a project governance and committer process. This is preferably laid out in a GOVERNANCE.md file and references a CONTRIBUTING.md and OWNERS.md file showing the current and emeritus committers. | Examples of these documents can be found in our main repository https://github.com/edgexfoundry/edgex-go Additionally, project governance and committer process is fully documented in our Wiki. Existing governance and contributor pages are located on this page and its subpages: https://wiki.edgexfoundry.org/display/FA/Technical+Work+in+the+EdgeX+Foundry+Project | |
Have a public list of project adopters for at least the primary repo (e.g., ADOPTERS.md or logos on the project website). | Our main repository contains the Adopter document (see https://github.com/edgexfoundry/edgex-go/blob/main/ADOPTERS.md) We also highlight user, adopters and commercial interests of EdgeX on our Website. |
...