Charter

The purpose of having a charter for the Developer Relations Foundation is to help people understand its mission and scope. The DevRel Foundation Charter is a living document, allowing the community to propose changes and updates as the project evolves.

Adopted June 3, 2024

Table of Contents

• Mission and Scope of the Project
• Steering Committee
• Voting
• Compliance with Policies
• Community Assets
• General Rules and Operations
• Intellectual Property Policy
• Amendments

Mission and Scope of the Project

• The mission of the Project is to elevate the professional practice of developer relations and increase awareness of it as a driver of business value.
• The scope of the Project includes collaborative development under the Project License (as defined herein) supporting the mission, including definitions, frameworks, and the creation and codification of other artifacts that aid in the mission of the open collaboration project.

Steering Committee

• The Steering Committee (the “SC”) will be responsible for all oversight of the open collaboration Project.
• The SC voting members are initially the Project’s Committers. At the inception of the project, the Committers of the Project will be set forth within the CONTRIBUTING file within the Project’s code repository. The SC may choose an alternative approach for determining the voting members of the SC, and any such alternative approach will be documented in the CONTRIBUTING file.
  Any meetings of the Steering Committee are intended to be open to the public and can be conducted electronically, via teleconference, or in person.
• SC projects generally will involve Contributors and Committers. The SC may adopt or modify roles so long as the roles are documented in the CONTRIBUTING file. Unless otherwise documented:
  • Contributors include anyone in the community that contributes code, documentation, or other artifacts to the Project.
  • Committers are Contributors who have earned the ability to modify (“commit”) source code, documentation or other artifacts in a project’s repository.
  • A Contributor may become a Committer by a majority approval of the existing Committers.
  • A Committer may be removed by a majority approval of the other existing Committers.
  • A Collaborator is a member of the community with read and write access to a repository who has been invited to contribute by the SC.
• Participation in the Project through becoming a Contributor and Committer is open to anyone so long as they abide by the terms of this Charter.
• The SC may:
  1. Establish workflow procedures for the submission, approval, and closure/archiving of projects
  2. Set requirements for the promotion of Contributors to Committer status
  3. Amend, adjust, refine and/or eliminate the roles of Contributors and Committers, and create new roles, documented publicly
• The SC may elect a SC Chair, who will preside over meetings of the SC and will serve until their resignation, term limit, or replacement by the SC.
• Responsibilities: The SC will be responsible for all aspects of oversight relating to the Project, including:
  • Coordinating the direction of the Project
  • Approving working groups based on evolving needs and priorities defined by the community
  • Organizing or removing sub-projects
  • Defining roles and processes for filling them
  • Creating sub-committees or working groups for cross-project needs
  • Appointing representatives to engage with other open source or open standards communities
  • Establishing community norms, workflows, release processes, and security issue reporting policies
  • Coordinating with the Series Manager as provided in Section 7 of this Charter
  • Facilitating discussions, seeking consensus, and conducting votes as needed
  • Coordinating marketing, events, and communications regarding the Project

Voting

• While the Project aims to operate as a consensus-based community, if a vote is needed, each voting SC or Working Group member has one vote.
• A two-thirds majority of all voting members is required for a vote to pass.
• Approval within a Working Group moves the item to the SC for final vote.
• If a vote cannot be resolved in a Working Group, any voting member may refer the matter to the SC.
• If the SC cannot resolve a vote, any SC voting member may refer the matter to the Series Manager.

Compliance with Policies

• This Charter is subject to the Series Agreement for the Project and the LF Projects Operating Agreement. Contributors will comply with LF Projects’ policies listed at:
  https://lfprojects.org/policies/
• The SC may adopt a Code of Conduct (“CoC”) subject to approval by the Series Manager. If no project-specific CoC exists, the LF Projects CoC applies.
• When adopting or amending policies, LF Projects will publish them at least 30 days before they take effect (except for Trademark Policy or Terms of Use, which are effective upon publication).
• All Collaborators must allow open participation under non-discriminatory terms.
• The Project will operate in a transparent, open, collaborative, and ethical manner at all times.
  All discussions, proposals, timelines, and decisions must be visible to the community.
  Any violations should be reported to the Series Manager.

Community Assets

• LF Projects will hold title to all trade or service marks used by the Project (“Project Trademarks”), which will be licensed to Collaborators.
• The Project may develop and manage its GitHub, social media accounts, and domain names under LF Projects’ license.
• LF Projects is not expected or required to take any action inconsistent with the tax-exempt status of the Joint Development Foundation or LF Projects, LLC.

General Rules and Operations

• The Project will:
  • Operate professionally and maintain community cohesion and goodwill with LF Projects, JDF, and other partners
  • Respect trademark rights and follow branding/trademark usage guidelines

Intellectual Property Policy

• Contributors retain copyright on their contributions as independent works.
• Unless otherwise stated:
  • Documentation is made available under Creative Commons Attribution 4.0 International License
  • Code must be licensed under an OSI-approved open source license
  • Contributions to Upstream Projects must comply with those projects’ license terms and contribution processes
• The SC may approve alternate licenses on an exception basis, requiring a two-thirds vote.
• All contributed files should include SPDX identifiers or other license information.

Amendments

• This Charter may be amended by a two-thirds vote of the entire SC, subject to approval by LF Projects.