Page History

...

Projects progress through a standard Project Lifecycle.

foo de foo.

Project Leadership Team and Project Lead

...

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.

NOTE:  This section is under revision for TSC and Board approval.  Please see Contributors, Committers & Maintainers for roles and current committer/maintainers lists.

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*

core-data-go*

core-metadata-go*

core-command-go*

core-domain-go

core-clients-go

support-logging-client-go

support-domain-go

support-notifications-client-go

consul-client-go

...

Applications

...

export-domain
export-client*
export-distro*
support-rulesengine*

export-go

...

Test/QA/Build/CI

...

ci-management
developer-scripts

* - 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).

...