| Table of Contents |
|---|
Updated 5/31/23 - per voted TSC changes during Napa Pre-Wire meeting
Technical Steering Committee
The TSC is a committee composed of technical leaders from the open source project responsible for oversight of the technical codebase, the technical community and release process.
The TSC operates in the context of the Project Technical Charter by these principals within this Code of Conduct.
...
The TSC is led by a Chair elected per the EdgeX Foundry Technical Charter.
The TSC Chair is responsible for acting as a liaison between the Governing Board and technical leadership of the Project, coordinating and leading the recurring TSC meetings and managing the overall TSC structure and work progress.
The TSC is comprised of the TSC Chair, each of the Working Group Chairs, and other members as specified in the EdgeX Foundry Technical Charter.
Working Groups
The TSC is comprised of Working Groups.
The term “Working Group” (WG) within the EdgeX Foundry Project will refer to an organizational unit of the Technical Steering Committee (TSC) focused on a specific technical domain e.g. Device Service Working Group.
Working Group Leadership
Each Working Group is led by a Working Group Chair who is elected from among project leadership team members of the projects in the Working Group. The Working Group Chair is responsible for coordinating the efforts of the various projects chartered in the Working Group.
Projects
Each Working Group has one or more Projects under it. The Working Group coordinates the efforts of these projects from an architectural, technical and organizational perspective to ensure that the work done by these projects is unified, consistent and aligned with the architecture and goals of the Working Group and the larger EdgeX Foundry Project.
The term “project” within the EdgeX Foundry Project will refer to a collaborative endeavor to deliver a work item.
A “Technical Project” is a collection of specific Maintainers, users and other developers, code, releases, issues, and other activity oriented around a common software-implemented mission. A Technical Project may be to develop a new capability or to refactor or remove an existing capability for the EdgeX technology releases. Such projects may take the form of a new component or may propose additions, deletions or changes to an existing component.
A 'Functional Project' is intended to produce a document, such as a requirements or use cases document, a white paper, or analysis and there are 'Technical' projects.
All projects have a page on the EdgeX Foundry Wiki.
New Projects are proposed using the Project Proposal Template.
Projects progress through a standard Project Lifecycle.
foo de foo.
Project Leadership Team and Project Lead
Projects in the EdgeX Foundry Project are managed by a Project Leadership Team. The leadership team is made up of distinguished community members, but the exact composition may depend on the project. The leadership team owns the projects processes, the overall architecture and all assets within the project and makes sub-project wide decisions on behalf of its community.
Project Leaders coordinate with the Chair of their respective working group through regular Working Group meetings to coordinate the efforts of all the projects that are chartered under a working group.
A projects leadership team members are listed on the sub-project's team portal (i.e. EdgeX Foundry Wiki).
The Leadership Team may elect a Project Lead who is also a member of the Leadership Team. Project Leads are the public figurehead of the project and are responsible for the health of the project. Project Leads can also act as referees should the Project Leadership Team become paralyzed.
Project Team Roles
Projects are driven by the people who volunteer for the job. This functions well for most cases.
The following table lists how each project uses these roles. Note that incubation projects have more flexibility in experimenting with roles that work for them, but need to define specializations before they can mature.
...
Maintainers
Maintainers own one or several components in the projects source tree. A maintainer reviews and approves changes that affect their components. It is a maintainer's prime responsibility to review, comment on, co-ordinate and accept patches from other community member's and to maintain the design cohesion of their components. Maintainers are listed in a MAINTAINERS file in the root of each code repository that the project owns.
Larger projects may have special maintainer roles such as a release manager and stable branch maintainers. In addition, larger projects may award different maintainers different levels of influence. Any specializations and implications are documented in the respective MAINTAINERS file.
Committers
Committers are Maintainers that are allowed to commit changes into the source code repository. The committer acts on the wishes of the maintainers and applies changes that have been approved by the respective maintainer(s) to the source tree. Due to their status in the community, committers can also act as referees should disagreements amongst maintainers arise. Committers are listed on the project's team portal on the EdgeX wiki and in the projects MAINTAINERS files.
Appointment of Committers and Maintainers
a. By default, project working group leads are committers for repositories assigned to their working group. At this time, EdgeX works off the following working group to repository assignments:
...
Working Group
...
Assigned project repositories
...
Device Services and Device Service SDK
...
device-virtual*
device-sdk
device-sdk-tools
device-X (where X is any new device service for a specific device)
...
Core and Supporting Services
...
core-domain
core-test
core-exception
core-data*
core-data-client
core-metadata*
core-metadata-client
core-command*
core-command-client
core-config-seed*
core-config-watcher*
support-domain
support-logging*
support-logging-client
support-notifications*
support-notifications-client
support-scheduler*
...
Applications
...
export-domain
export-client*
export-distro*
support-rulesengine*
...
Test/QA/Build/CI
...
ci-management
developer-scripts
Each Working Group must have a chair and optionally a co-chair (or vice-chair). The Co-chair role assists in working group leadership and serves as a proxy for the chair when the work group chairperson is not present/available. While not official, the co-chair serves as heir apparent for the chair role for future project efforts. Each Working Group has a single vote in TSC matters - it can be either the chair or co-chair (i.e. - only one vote for TSC matters is given to each work group) .
Working Groups
The TSC is comprised of Working Groups.
The term “Working Group” (WG) within the EdgeX Foundry Project will refer to an organizational unit of the Technical Steering Committee (TSC) focused on a specific technical domain e.g. Device Service Working Group.
Working Group Leadership
Each Working Group is led by a Working Group Chair who is elected from among project leadership team members of the projects in the Working Group. The Working Group Chair is responsible for coordinating the efforts of the various projects chartered in the Working Group.
Projects
Each Working Group has one or more Projects under it. The Working Group coordinates the efforts of these projects from an architectural, technical and organizational perspective to ensure that the work done by these projects is unified, consistent and aligned with the architecture and goals of the Working Group and the larger EdgeX Foundry Project.
The term “project” within the EdgeX Foundry Project will refer to a collaborative endeavor to deliver a work item.
A “Technical Project” is a collection of specific Maintainers, users and other developers, code, releases, issues, and other activity oriented around a common software-implemented mission. A Technical Project may be to develop a new capability or to refactor or remove an existing capability for the EdgeX technology releases. Such projects may take the form of a new component or may propose additions, deletions or changes to an existing component.
A 'Functional Project' is intended to produce a document, such as a requirements or use cases document, a white paper, or analysis and there are 'Technical' projects.
All projects have a page on the EdgeX Foundry Wiki.
New Projects are proposed using the Project Proposal Template.
Projects progress through a standard Project Lifecycle.
Project Leadership Team and Project Lead
Projects in the EdgeX Foundry Project are managed by a Project Leadership Team. The leadership team is made up of distinguished community members, but the exact composition may depend on the project. The leadership team owns the projects processes, the overall architecture and all assets within the project and makes sub-project wide decisions on behalf of its community.
Project Leaders coordinate with the Chair of their respective working group through regular Working Group meetings to coordinate the efforts of all the projects that are chartered under a working group.
A projects leadership team members are listed on the sub-project's team portal (i.e. EdgeX Foundry Wiki).
The Leadership Team may elect a Project Lead who is also a member of the Leadership Team. Project Leads are the public figurehead of the project and are responsible for the health of the project. Project Leads can also act as referees should the Project Leadership Team become paralyzed.
Making Contributions
* - denotes additional Docker repos associated to this project
b. Committers will nominate maintainers for their assigned repositories to the TSC for approval.
c. The TSC may appoint other committers and maintainers as it sees fit based on architectural purview of the project, knowledge of the project, volume of contributions, etc.
The current committers list approved by the TSC are:
- Applications: Janko Isidorovic
- Core/Support: Jim White
- Device Service/SDK: Tony Espy
- Test/QA/Builds: Andy Foster
Additional General / Global Committers Nominees:
- Jim White
- Tyler Cox
- Andrew Foster
Security Response Team (short: Security Team)
Each project may have a security response team, that is responsible for receiving, reviewing, and responding to security incident reports for the sub-projects assets according to its security response process (e.g. Hypervisor Security Problem Response Process).
Making Contributions
...
The EdgeX Foundry Project does not require community members to sign contribution or committer agreements. We do require contributors to sign contributions using the sign-off feature of the code repository, following the same approach as the Linux Kernel does (see Developer Certificate Of Origin).
...
- Contribution Guidelines
- Review Then Commit Policy
Release Process
...
Code is released under the following Release Taxonomy.
...