Updated   by vote of the TSC


The Tungsten Fabric technical project has been established as TF Project a Series of LF Projects, LLC (“TF” or, alternatively, the “Project”). LF Projects, LLC is a Delaware series limited liability company. Governance for the Project is detailed within the Project Technical Charter available at Tungsten.io (“Charter”). This Technical Community Document is intended to provide additional operational guidelines for the Project, and is subject to the Technical Charter.

1    Guiding Principles 

The Tungsten Fabric Project a Series of LF Projects, LLC (“TF”) will operate transparently, openly, collaboratively, and ethically. Project proposals, timelines, and status must not merely be open, but also easily visible to outsiders.

2    Structure of the Technical Community

The Technical Community consists of multiple projects and a Technical Steering Committee that spans across all projects.

3    Per Project

3.1  Project Roles 

3.1.1   Contributor

A Contributor is someone who contributes to a project. Contributions could take the form of code, code reviews, or other artifacts. Contributors work with a project’s Committer and the project’s sub-community. A Contributor may be promoted to a Committer by the project’s Committers after demonstrating a history of meritocratic contribution to that project.

3.1.2   Committer

For each project there is a set of Contributors approved for the right to commit code to the source code management system (the “Committers”) for that project. 

      • Committer rights are per project; being a Committer on one project does not give an individual committer rights on any other project.
      • The Committers will be the decision makers on all matters for a project including design, code, patches, and releases for a project.
      • Committers are the best available individuals, but usually work full-time on components in active development.

In order to preserve meritocracy in selection of Committers while ensuring diversity of Committers, each initial project are encouraged to taking on at least three Committers from different companies (subject to meritocracy).

3.1.3   Project Technical Leader:

A project is required to elect a Project Technical Leader (“PTL”). The PTL acts as the de facto spokesperson for the project. Project Technical Leader Candidates

Candidates for the project’s Project Technical Leader will be derived from the Committers of the Project.

Candidates must self nominate. Project Technical Leader Voters

Only Committers for a project are eligible to vote for a project’s Project Technical Lead. Project Technical Leader Election Mechanics

An election for Project Technical Leader occurs when any of the following are true:

        • The project is initially created
        • The Project Technical Leader resigns his or her post
        • The majority of committers on a project vote to call a new election
        • One year has passed since the last Project Technical Leader election for that project

3.2  Project Operations

3.2.1   Project Decisions Making Process

Technical and release decisions for a project should be made by consensus of that project’s Committers.  If consensus cannot be reached, decisions are taken by a majority vote of a project’s Committers.  Committers may, by majority vote, delegate (or revoke delegation) of any portion of such decisions to an alternate open, documented, and traceable decision-making process.

3.2.2   Committer Lifecycle     Adding Committers

        • Initial Committers for a project will be specified at project creation 
        • Committer rights for a project are earned via contribution and community trust. Committers for a project select and vote for new Committers for that project, subject to TSC approval.
        • New Committers for a project should have a demonstrable established history of meritocratic contributions.     Adding Committers to moribund projects

In the event that a project has no active committers (e.g., due to resignations, etc.), the TSC may appoint an interim Committer from a project’s active Contributors. This term shall last until the next release date, after which time the Committer must stand for election from amongst other Committers on the project to maintain his or her status.  In this special case, approval requires a majority of committers who respond within two weeks. If no one responds by the deadline, then the committer status is approved. This provision allows a project to continue development following an unexpected change in personnel.

The method by which the TSC appoints an interim committee is first by request to the TSC email list indicating the request to appoint an interim Committer for a project.  After the reception of such an email, the normal TSC decision process applies.     Removing Committers

A Committer may voluntarily resign from a project by making a public request to the PTL to resign (via the project and TSC email lists).

A Committer for a project who is disruptive, or has been inactive on that project for an extended period (e.g., six or more months) may have his or her Committer status revoked by the project’s Project Technical Leader or by 2/3 super-majority vote of the project’s committers.

The Project Technical Leader is responsible for informing the Technical Steering Committee (TSC) of any committers who are removed or resign via the TSC email list.

Former committers removed for reasons other than being disruptive may be listed as ‘Emeritus Committers’.  That title expresses gratitude for their service but conveys none of the privileges of being a Committer.

3.2.3   Umbrella Projects

The TSC may create umbrella projects (“Umbrella Projects”) that in turn support multiple sub-projects. Umbrella Projects will be led by an Umbrella Committee made up of the PTL and one or more committers, who are the committers of each of the subprojects. Each subproject will have its own set of committers with responsibility only for the subproject repository.

With the approval of the TSC, Umbrella Projects may establish and modify additional technical roles for sub-project participants.

3.3  Project Lifecycle

3.3.1   Project Lifecycle

The activities of the TF community are articulated around projects and releases. The scope of each project is aligned with the TF architecture and the scope of each release is defined with the objective to fulfill a particular use case(s).

A project is a long term endeavor setup to deliver features across multiple releases, which have a shorter lifespan.

The project and release lifecycle are simple and provide sufficient visibility to allow teams to coordinate with one another and flock naturally.

The key point of the project and release lifecycle process is to provide adequate visibility to all stakeholders, provide synchronization, and support to all contributors.

This document covers the TF project lifecycle. The Release Lifecycle is documented in a separate document (include link when ready).

3.3.2   Project Lifecycle Overview

The project lifecycle provides the freedom for each team to conduct its project according to their needs, culture and work habits. Thus, the project lifecycle is not prescriptive on how each project operates.

An TF release can be composed of 1 to N projects. As such the number of contributing projects to a particular release may vary overtime.

A release is initiated to deliver a set of project deliverables.

The project lifecycle process does not impose a duration for the project nor for the release. There is an independent Release Plan document for each release to specify release timelines.

3.3.3   Project Lifecycle States and Reviews

TF project lifecycle defines five states that each project goes through. The project lifecycle may extend across multiple releases.
The procedure of moving from one state to the next one is independent from the release and the pace depends on each individual project.

In order to effectively review project progress, four reviews are build-in within the project lifecycle.

The lifecycle of a project is depicted on the following diagram:

Project State



Project doesn’t really exist yet, may not have real resources, but is proposed and is expected to be created due to business needs.


Project has resources, but is recognized to be in the early stages of development. The outcome is a minimum viable product (MVP) that demonstrates the value of the project and is a useful vehicle for collecting feedback, but is not expected to be used in production environments.


Project is fully functioning and stable, has achieved successful releases.


Project provides value to and receives interest from a broad audience.


Project can reach Archived state for multiple reasons. Either project has successfully been completed and its artifacts provide business values, or project has been cancelled for unforeseen reasons (no value anymore, technical, etc.).

Project in any state can be Archived through a Termination Review.

To move from one state to the next state, the Project Team has to formulate a Kick-Off release review to the TSC, by specifying its goal to move up the Project Lifecycle ladder.

From State

To State

Review Description





Incubation review



Maturity review



Core review



Termination review

Note 1: Project proposals are posted in the “Proposed Projects” section of the TF wiki.  Approved projects are posted to the “Approved Projects” section of the TF wiki.

Note 2: The proposal submitter can decide to remove projects in “proposal” state that do not progress to incubation state.

3.3.4   Tailoring

A project’s release cycle may be tailored by allowing some exceptions to the normal release process. Tailoring may be initiated in two ways:

      1. By the TSC voting members: TSC voting members reserves the right to allow changes to the process in order to meet criteria that were initially unknown.
      2. By Project Team Lead: Any project team lead can email TSC voting members to request tailoring the process for a particular release. The key point in tailoring is to anticipate as much as possible, to justify the request, and document the request in the wiki.

Tailoring practices will be documented as we progress through our releases. The TSC should respond to requests in a timely manner.

3.3.5   Reviews & Metrics Overview

Project promotion across states can only be done by TSC review and voting. During the reviews the candidate projects are evaluated based on predefined metrics and KPIs. The target numbers may vary for each project and state.

      • Longevity of the project
      • Project follows (or doesn't) the TF release cadence
      • Requirements have resulted in corresponding implementations
      • Comprehensiveness and maturity of the artifacts (code, test cases, documentation) the project produces including contributions/code to partner/upstream projects where applicable
      • Mature testing/integration success for defined environments (TF and/or partner/upstream projects, which is applicable or both)
      • Project artifacts: it is expected that all projects artifacts are available and accessible to all contributors of the TF community. Links toward projects artifacts must be provided
      • Community
        • Size and diversity of the active community (number and diversity of people contributing)

For each and every review the following steps are required:

      • The project review is posted two weeks in advanced in the Release Wiki. This allows all contributors to provide feedback prior to the review meeting. (include link when available)
      • The project review is emailed to tsc@lists.tungsten.io mailing list
      • Disposition by TSC: Confirm that the project state is complete and the listed requirements are met.
      • Simple majority approval by voting TSC members

Reviews for multiple projects can occur at the same time.

During Release Kick-Off, the project team may request that the TSC conduct a review to move up the ladder.

3.3.6   Project Reviews     Incubation Review

The goal of the Incubation Review is to officially launch the project and to support its needs until project Termination Review.

Once a project has passed the Incubation Review, the project is in Incubation State and may span over multiple releases.

Proposal template is available at Proposal Template.

The following artifacts are expected:

        • Name of the project is appropriate (no trademark issues etc.); Proposed repository name is all lower-case without any special characters
        • Project contact name, company and email are defined and documented
        • Description of the project goal and its purpose are defined
        • Scope and project plan are well defined
        • Resources committed and available
        • Contributors identified
        • Initial list of committer identified (elected/proposed by initial contributors)
        • Meets TF TSC Policies
        • Proposal has been socialized with potentially interested or affected projects and/or parties
        • Cross Project Dependencies (XPDs). In the case where a project will require changes in other projects, those projects are listed in the proposal, and a sponsoring developer in the project has been identified
        • Tools have been identified and discussed with relevant partners (Linux Foundation, IT). Once the project pass the review, the tools chain must created within one week. Tools encompass Configuration Management, CI-CD, Code Review, Testing, Team Wiki, End Users documentation (not exhaustive)     Maturity Review

The goal of the Maturity Review is to ensure:

        • Artifacts for Incubation State are complete and accepted
        • Plan for Maturity State are accepted

Once a project has passed the Maturity Review, the project is in Mature State and may span over multiple releases.

Review metrics for Maturity review:

        • Successful participation in releases: The project demonstrates stable output (code base, documents) within its history of releases in accordance with the release policy.
        • Architecture has been reviewed by the Architecture Committee
        • Project is active and contributes to TF: The project demonstrates a stable or increasing number of contributions across recent releases. Contributions are commits which got merged to a repository of a TF project or a related upstream project. Commits can for example be patches to update the requirements document of a project, code addition to a TF or upstream project repository, new test cases and so forth.
        • Mature artifacts produced: The project demonstrates that the artifacts produced by the project are deployable (where applicable) and have been successfully deployed, configured, and used by end users (typically, service providers).     Core Review

The goal of the Core Review is to ensure:

        • Artifacts for Maturity State are complete and accepted
        • Plan for Core State are accepted. For the Core Review it is expected to deliver a comprehensive integration plan

Once a project has passed the Core Review, the project is in Core State and may span over multiple releases.
Review metrics for Core review include the metrics for maturity review plus the following:

        • Contributor diversity: The project demonstrates that it has a stable core team of contributors/committers which are affiliated to a set of at least two different companies. Core team members are those who have been active on the project for more than two releases, which means they were reviewing contributions to the project in TF Code Review and/or in the review-tool of the target upstream project(s).
        • Recognized value through other projects: The project demonstrates that its results are leveraged by other TF projects in an ongoing way, i.e. for at least the last two releases.
        • Successful integration tests (only applicable to projects which provide features/functionality): The project demonstrates that component tests and system-level tests have been implemented, that tests are used within the TF CI/CD test pipeline, and that tests bear successful results.
        • Stability, Security, Scalability and Performance levels have reached a high bar.     Termination Review

The goal of the Termination Review is to ensure that:

        • Artifacts for Core state are complete and accepted
        • Core project artifacts are acceptable and meet the acceptance criteria
        • Project Team has the confidence that its artifacts can be used outside the TF community
        • Metrics for Termination review are available

3.3.7   Mature Release Process

A Project’s Committers make all decisions about Releases of that Project.  However, to be eligible to be considered ‘Mature’, the project must demonstrate a history of following the Mature Release Process.  The purpose of the Mature Release Process is to insure openness and maximum opportunity for participation.  The idea is to have a simple, clear, public declaration of what a project intends to do and when, and what was actually done in a release cycle.   Towards that end, a project following the ‘Mature Release Process’ should have a Release Plan published at the beginning of its release cycle by its committers, and a Release Review just prior to the project release.

Both Release Plan and Release Review documents are intended to be relatively short, simple, and posted publicly on the wiki to assist the project in coordinating the amount themselves and the general world in gaining visibility.

These should contain roughly the following sections:     Release Plan

        • Introduction
        • Release Deliverables
        • Release Milestones
        • Expected Dependencies on Other Projects
        • Compatibility with Previous Release
        • Themes and Priorities
        • Other
        • Features delivered
        • Non-Code Aspects (user docs, examples, tutorials, articles)
        • Architectural Issues (if any)
        • Security Issues (if any)
        • Quality Assurance (test coverage, etc)
        • End-of-life (API/Features EOLed in Release)
        • Summary of Outstanding Bugs
        • Summary of Standards Compliance
        • Delta between planed schedule and actual schedule     Release Review

        • Features delivered
        • Non-Code Aspects (user docs, examples, tutorials, articles)\
        • Architectural Issues (if any)
        • Security Issues (if any)
        • Quality Assurance (test coverage, etc)
        • End-of-life (API/Features EOLed in Release)
        • Summary of Outstanding Bugs
        • Summary of Standards Compliance
        • Delta between planed schedule and actual schedule

3.4  Amendments to the Technical Community Document

The TSC may make amendments to this Technical Community Document at any time. The charter amendment process is for a TSC voting member to propose changes that will be decided by simple majority of the full TSC. The proposed changes are subject to review and approval by the Series Manager of TF.

4    Technical Steering Committee

4.1  TSC Roles

4.1.1   TSC Members TSC Membership Definitions

    • Active Community Members:   Anyone from the TF community with twenty (20) or more measurable contributions during the previous 12-month period, inclusive of code merged, code reviews performed, wiki page edits, or JIRA activities. TSC Size, Structure, and Member Requirements

      • The TSC shall consist of four (4) seats 
      • Four (2) seats on the TSC are to be reserved for Committers with 5 or more measurable commits within the last 12 months.
      • Four (2) seats on the TSC are to be reserved for Active Community Members as defined in
      • TSC members shall be Active Community Members, notwithstanding the exception granted in section
      • For purposes of avoiding dominance from a particular company, also define any given company as a Represented Group with no seats (and thus no need to define voters):

        • for company_var in <the set of all companies>:

        • Represented Group company_var * Min Seats: 0 * Max Seats: cap of 2 per group

        • Candidates: Works for company_var

4.1.2   TSC Chair

The TSC will elect from amongst voting TSC members a chairperson for a term of one year according to the Tungsten Fabric Technical Charter. The TSC shall hold elections to elect a TSC Chair annually; there are no limits on the number of terms a TSC Chair may serve.     Responsibilities

The primary responsibility of the TSC Chair is to represent the technical community in communications with the LF Networking Fund of The Linux Foundation and to be responsible for:

        • Leading TSC meetings;
        • This responsibility may be delegated to another TSC member  (in such case, this is to be informed via the TSC email list)
        • Representing the technical community to external organizations.
        • These responsibilities may be delegated to another member of the technical community.
        • Lead the TSC in the execution of the TSCs responsibilities (section 4.3).

4.1.4   Coordinators     Coordinator Description

The TSC has multiple coordinator roles.  Each coordinator role comes with its own set of responsibilities to discharge in serving the community via coordinating among various parties. 

A coordinator is an internal role, so while a coordinator may coordinate among various external liaisons in some instances, being a coordinator does not imply being the liaison to any particular external organization or group of organizations.

Coordinators support the TSC Chair in the execution of TSC responsibilities (Section 5.3) and the delivery of TF releases. They are responsible for fostering collaboration among the many parties that need to work together to identify, characterize, and solve problems, they do not direct solutions.     Coordinator origin.

The Technical Steering committee may elect coordinators from the Technical Steering Committee or from community participants.  The TSC will solicit nominations for the role. Nominees should have subject matter experience in the relevant coordination area. In the event that multiple candidates self-nominate, the TSC will hold an election.

Elections are held annually. There are no limits to the number of terms an individual can serve.

The coordinator will regularly report status and issues to the TSC via the TSC email list.     Coordinator and coordination area lifecycle

There is a lifecycle for the coordinator responsibility (coordination area) and the coordinator appointment.

Coordination Area Creation

A coordination area is created by sending a request to the TSC via the TSC email list.  The email shall have:

-        Email Subject: Creation Request for coordination area: <coordination area name>

-        Coordination Area responsibility description: <Description of the coordination area responsibilities>

-        Reporting Cadence: <description of when reporting is expected to be delivered to the TSC>

-        Area Coordinator: <Name of the area coordinator> (Can be blank)

The decision to create the coordination area is created by a TSC decision (per the TSC voting rules).  A decision can be made with modification, with the modifications captured in the TSC minutes.  Once a coordination area is created, it will be documented in the TF Wiki.

For the Area coordinator, see section:

Coordination Area Update

-        A coordination area can be updated by sending a request to the TSC via the TSC email list.  The email shall have the following: Email subject: Update Request for coordination area: <coordination area name>

-        Proposed Update: <Clearly described update of the coordination area. This could be the Area Responsibility Description; Reporting Cadence; Area Coordinator>.

The decision to update the coordination area is created by a TSC decision (according to the TSC voting rules).  An update decision can be made with modification, with the modifications captured in the TSC minutes.  Once a coordination area is updated, the updates will be documented in the TF Wiki.

Coordination Area Termination.

A coordination area can be terminated by sending an email to the TSC via the TSC email list.  The email shall have the following.

-        Email Subject: Close Request for coordination area: <coordination area name>

-        Motivation: <Motivation for closing the coordination area>.

The decision to close the coordination area is created by a TSC decision (according to the TSC voting rules).  Once a coordination area is updated, the coordination area will be removed from the TF Wiki.

4.2  TSC Operations

4.2.1   TSC Decision Making Process

Decisions of the TSC should be made by majority vote of TSC Members.

4.2.2   TSC Chair/Coordinator Elections

The TSC Chair/Coordinators shall be elected separately.  There is no prohibition against a person holding multiple roles.     TSC Chair Candidates

Candidates for TSC Chair must be TSC Members as defined in Section 4.1.1.

Candidates must self-nominate.     Coordinator Candidates

Any community member (regardless of TSC membership) is eligible to serve as a coordinator.  Nominees should have subject matter experience in the relevant coordination area.

Candidates must self-nominate.     TSC Chair/Coordinator Voters

Only TSC Members (Section 4.1.1) are eligible to vote for TSC Chair/Coordinator.     TSC Chair/Coordinator Election Mechanics

Election of a TSC Chair/Coordinator shall use a multiple-candidate method, e.g.:

Condorcet: http://en.wikipedia.org/wiki/Condorcet_method; or Single Transferable Vote: http://en.wikipedia.org/wiki/Single_transferable_vote

4.2.3 TSC Member Elections Candidate and Voter Eligibility

      • Any Active Community Member (regardless of LFN membership), is eligible to run for a TSC seat, except as provided for in section
      • Any Active Community Member (regardless of LFN membership), is eligible to vote in a TSC election
      • Eligibility is effective as of the date and time the nomination process starts TSC Member Candidates

      • There are no limitations on the number of candidates that can run for a TSC seat, nor is there a limit to the number of candidates from any company, or group of related companies that can run in a TSC election
      • Candidates must self nominate
      • TSC Member Election Mechanics
        • The election of a TSC Member shall consist of a single stack ranked vote of all candidates via CIVS ( Condorcet: http://en.wikipedia.org/wiki/Condorcet_method);  
        • The top ranked candidate from each Operator will be selected, for a total of nine members, one member from each Operator
        • The top ranked non-Operator candidates (whether affiliated with a company or an individual contributor), will be selected for the remaining nine seats, with no more than one member per company or group of related companies being selected. TSC Member Standing Down

        • If a TSC member is no longer able to perform the TSC duties, the TSC member may inform via an email to the TSC email list.
        • If a TSC member moves companies, that member must notify the TSC via an email to the TSC email list.  That TSC member may remain a member unless: 1) the moves places the member in conflict with the TSC composition rules, or 2) the TSC member (at his/her determination) will no longer be able to perform their TSC duties. Replacement of a TSC member standing down

        • In the event of a TSC member standing down:
          • If the TSC position is from one of the elected positions (i.e. non reserved seat), an election for that single position is held within 60 days of notification. The conditions of the election are the same as for any TSC election.
        • If the said position was of that of a TSC chair, then the TSC chair position will undergo re-election after the successful appointment or election of the new TSC member.
        • When the next General TSC election is held, any seat filled via will also be included in the general TSC election.

4.3  Responsibilities of the TSC. 

Subject to the Technical Charter, the TSC is responsible for:

    • Defining Tungsten Fabric’s release vehicles (such as a Coordinated Release) that align with the Project’s mission,
    • Fostering cross-project collaboration,
    • Serving as TF’s primary technical liaison body with other consortiums and groups,
    • developing an architecture,
    • setting simultaneous release dates,
    • defining release quality standards,
    • defining technical best practices and community norms (including the establishment and maintenance of a Development Process),
    • monitoring technical progress,
    • mediating technical conflicts between Committers and PTLs,
    • organizing inter-project collaboration,
    • coordinating technical community engagement with the end-user community.

4.4  TSC Subcommittees

The TSC, at its discretion, may establish subcommittees to assist the TSC with its responsibilities and provide expert guidance in technical subject areas (e.g., architecture or security).

4.4.1   Membership Subcommittee Membership Eligibility

Each subcommittee shall determine its own membership eligibility, in consultation with the TSC. It is expected that subcommittee membership shall be open to all TF Contributors; however, subcommittees may impose restrictions such as the number of participants from a single company. While the desire may be to keep its size and scope limited, each subcommittee shall be open to the TF membership.  Also, all elected TSC members are eligible to join a subcommittee   Subcommittee Chair / Vice Chair

Each subcommittee may elect a Chair and optionally a Vice-Chair who is responsible for leading meetings and representing the subcommittee to the TSC.    Subcommittee Chair / Vice Chair Elections

The Chair or Vice-Chair will be elected by members of the subcommittee as of the date the nomination process starts for the election.    Subcommittee Voter Eligibility

Voting for a Chair or Vice-Chair is not limited to Tungsten Fabric member companies. However only 1 Subcommittee member from each company, or group of related companies may vote in the election.

For the purpose of this document, “Related Company” shall mean any entity (Company-A) which controls or is controlled by another entity (Company-B) or which, together, is under the common control of a third party (Company-C), in each case where such control results from ownership, either directly or indirectly, of more than fifty percent of the voting securities or membership interests of the entity in question; and “Related Companies” are entities that are each a Related Company as described above.    Subcommittee Election Confirmation

The elected Chair (and/or Vice-Chair) is submitted to the TSC for confirmation. The TSC decides to accept the outcome or requests a new voting. 

4.4.2   Advisory role

Subcommittees are advisory in nature, and not authoritative. They provide advice to projects and to the TSC.

Subcommittees operate on a rough consensus basis.  If the subcommittee is unable to reach consensus on what advice to offer, the subcommittee Chair shall raise the issue with the TSC, where a formal vote can be taken, or advise the project that the subcommittee cannot reach consensus. 

4.4.3   TSC subcommittee lifecycle.     Creation of a TSC subcommittee

The TSC decides the creation of a subcommittee in accordance with TSC decision procedure.

In order to create a TSC subcommittee, a TSC member shall make a proposal to the TSC (via TSC email list) that that shall cover at least the following:

        • TSC subcommittee name.
        • TSC subcommittee purpose: <Description of subcommittee purpose>
        • TSC subcommittee expected deliverables:<List of expected deliverables>
        • TSC subcommittee starting participants: <List of expected starting participants>
        • Optionally TSC subcommittee definition of done: <Description of what is expected at the conclusion of the subcommittee.  This may relate to the deliverables>     Update of a TSC subcommittee

The TSC can modify a TSC subcommittee via a TSC decision.  To request such a modification, a request is made to the TSC email list.     Conclusion of a TSC subcommittee

The TSC decides the termination of the TSC subcommittee in accordance with the TSC decision procedure.  The submission of a request to terminate the TSC subcommittee should cover:

        • TSC subcommittee name
        • TSC subcommittee deliveries: <description of what has been achieved>
        • Motivation for termination of TSC subcommittee: <Reason for requesting the termination of the subcommittee>

4.4.4   Subcommittee vs. coordinator

As a guideline, a subcommittee is most appropriate when the task to be addressed involves a relatively stable group of people with a high level of intersection of common involvement.  A coordinator is more appropriate when there is a more dynamic group of people and issues may change frequently. A coordinator is also more appropriate for smaller efforts or topics requiring infrequent meetings.

  • No labels