PHP: rfc:working_groups

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== PHP RFC: Working Groups ======

  * Date: 2025-02-17
  * Author: Ben Ramsey, <ramsey@php.net>
  * Status: Draft
  * First Published at: http://wiki.php.net/rfc/working_groups

===== Introduction =====

This document establishes a framework for the creation, operation, and dissolution of Working Groups within the PHP Project. It provides a structured, transparent mechanism for managing discrete projects or activities (whether technical, infrastructural, or otherwise) undertaken by the Community. As such, it ensures that each Working Group is clearly chartered, time-bound, and actively led, thereby addressing organizational gaps that often leave new and existing volunteers uncertain about who to talk to or how to contribute.

==== Terms ====

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [[https://www.rfc-editor.org/bcp/bcp14.txt|BCP 14]] [ [[https://datatracker.ietf.org/doc/html/rfc2119|RFC2119]] ] [ [[https://datatracker.ietf.org/doc/html/rfc8174|RFC8174]] ] when, and only when, they appear in all capitals, as shown here.

“Community” means the broad, worldwide group of individuals and organizations who use or have an interest in the PHP Project.

“PHP Project” means the websites, documentation, infrastructure, mailing lists, and software accessible through PHP.net and managed as part of the whole project.

“PHP RFC process” means the process for proposing changes to the PHP programming language or PHP Project policies, as defined in https://github.com/php/policies/blob/main/feature-proposals.rst.

===== Working Groups =====

==== Creation ====

Using the PHP RFC process, any Community member or group of Community members may propose a Working Group.

==== Scope ====

Each Working Group is responsible for the active management of one or more PHP Project projects or activities identified by the Working Group Charter, which may include, without limitation, the creation or maintenance of open source software, infrastructure, outreach and educational programs, or language and policy change proposals.

Creating a Working Group is not a requirement for creating a PHP RFC, but Working Groups MAY propose PHP RFCs as part of their activities. If a Working Group’s activities include making changes to the PHP programming language and/or PHP Project policies, the Working Group MUST follow the PHP RFC process to propose these changes.

==== Proposal ====

The proposal to create a Working Group MUST follow the PHP RFC process.

The PHP RFC that proposes a Working Group MUST include the Working Group Charter, and the charter MUST specify at least the following:

  - the purpose and mission of the Working Group and how it relates to the PHP Project,
  - the project(s) and/or activity(ies) the Working Group will undertake,
  - the methods the Working Group will use to achieve its mission,
  - the initial members of the Working Group or how the Working Group will select its members,
  - the chairperson of the Working Group or how the Working Group will select its chairperson, and
  - the methods the Working Group will use to communicate with its members, the PHP Project, and the Community.

The Working Group Charter MAY specify the maximum length of time before the Working Group requires rechartering.

==== Responsibilities ====

Each Working Group SHALL designate a chairperson who is the primary responsible party for projects and activities managed by the group. The chairperson MAY establish rules and procedures for the day-to-day management of projects and activities for which the group is responsible.

Each Working Group MUST publish an annual public report describing its activities and accomplishments. In addition, each group SHOULD publish quarterly or semiannual public updates to inform the Community on the status of its activities.

Working Group operations, including but not limited to meetings, discussions, decisions, and work activity, SHOULD be open and transparent.

==== Working Group Policies ====

Through the PHP RFC process, the Community may set policies or procedures which apply to Working Groups. These policies or procedures MAY apply to individual Working Groups, multiple Working Groups, or all Working Groups. The chairpersons of affected Working Groups are responsible for implementing and adhering to the policies or procedures which apply to them.

==== Termination ====

Unless stated otherwise in the Working Group Charter, each Working Group dissolves one (1) year from the date of its acceptance (the “automatic mechanism”).

The Community may propose a dissolution RFC to dissolve a Working Group at any time. The RFC to dissolve a Working Group MUST include a statement explaining the reason(s) for dissolving the Working Group.

When a Working Group nears dissolution or is dissolved, either at the time stated in the Working Group Charter, through the automatic mechanism, or by the acceptance vote of a dissolution RFC, the Working Group MAY be rechartered by creating a new PHP RFC with a new Working Group Charter.

===== PHP Project Considerations =====

Upon acceptance, this PHP RFC adds a new document, ''%%working-groups.rst%%'', to the [[https://github.com/php/policies|PHP policies repository]]. The document ''%%working-groups.rst%%'' MUST contain the contents of the //Introduction// and //Working Groups// sections of this RFC.

===== Proposed Voting Choices =====

Allow the creation of PHP Project Working Groups, according to the framework defined in this proposal?

//Yes/No//

===== Non-normative Discussion =====

==== Rationale ====

=== “I Want To Help. Who Do I Talk To?” ===

The PHP Project has difficulty recruiting and welcoming new contributors, not because it is mean or toxic, but because it has a governance problem—or, rather, a lack of governance problem. There’s no shortage of work to do, and there’s no shortage of folks who are interested in volunteering, but PHP doesn’t have the structures in place to point would-be volunteers in the right directions, so the conversations often begin and end with, “Hey! I’d like to help out. Who do I talk to?”

Lack of governance isn’t necessarily a bad thing—though, lack of governance is a gross mischaracterization. Without a formalized structure, project governance is implied. As the authors of //[[https://www.theopensourceway.org/the_open_source_way-guidebook-2.0.html#_project_and_community_governance|The Open Source Way]]// put it, “Because open source projects are organizations, every one features governance structures. Some of these structures are more //explicit// than others. Some are more //formal// than others. But every project has them.”

=== The PHP Do-ocracy ===

//The Open Source Way// later describes a type of governance model that sounds much like the one PHP has, calling it a //do-ocracy//:

> Open source projects adopting the “do-ocracy” governance model tend to forgo formal and elaborate governance conventions and instead insist that “decisions are made by those who do the work.” In other words: In a do-ocracy, members gain authority by making the most consistent contributions.

This way of working can lead to problems when trying to welcome newcomers. “As a result, joining [these projects] can be difficult and intimidating for newcomers, as would-be contributors might not immediately know how to participate or seek approval for their contributions.”

The PHP Project, to its credit, recognized long ago some of the problems with its implied governance model and has gradually implemented and formalized an [[https://github.com/php/policies/blob/main/feature-proposals.rst|RFC process]] that is well-defined and transparent. [[https://lwn.net/Articles/821821/|John Coggeshall wrote]] of PHP’s RFC process that it “has done a great deal to democratize these conflicts and move away from the benevolent dictator approaches of the past […] One welcome thing it does provide is a clear path for new contributors to make small contributions, such as a single useful function, and succeed in seeing their ideas make it into releases without a great deal of turmoil.” He continues, “For the contributor who is looking to become involved in heavier project decisions however, they will still find it to be at times a discouraging process.”

In “[[https://doi.org/10.1145/3570635|For a More Transparent Governance of Open Source]],” researchers Cánovas and Cabot performed a review of governance models across many open source projects and found:

> The lack of key governance information deters potential contributors, as they may feel the onboarding process would be too time consuming or may fear there are hidden power relations in the project that could limit their impact. The same goes for end users, who may decide among similar projects based on how healthy and transparent the community behind them is.

PHP’s do-ocracy governance model turns away new and eager volunteers because there’s no clear and transparent ownership over certain areas of the PHP Project, and in areas where the ownership is clear, the owner might no longer have the time to work with and lead volunteers. This discourages volunteers, and their initial eagerness and excitement to help can fizzle out. The PHP Project needs to harness this eagerness and excitement and take advantage of it before it fizzles out.

=== Solving the “Who Do I Talk To?” Problem ===

The goal of this RFC is //not// to introduce hierarchy to the PHP Project. The goal is not to change the do-ocracy governance model. **The goal is to solve the “Who do I talk to?” problem in a way that does not centralize authority or consolidate it for lengthy periods of time under one person or group of people** (where any particular initiative is bound to find itself dormant and in a state of limbo, leading back to the question “Who do I talk to?”).

It accomplishes this in three key ways:

  - The scope of a working group is targeted to a specific endeavor.
  - A working group must have a clearly-identified responsible party.
  - A working group is time-boxed and expires after a fixed period of time.

This solves the “Who do I talk to?” problem by:

  - Explicitly defining the project. This is the “what” the would-be volunteer is interested in volunteering to help with.
  - Explicitly defining the chairperson and group members. This is the “who” the would-be volunteer can talk to.
  - Setting an expiration date. If a working group has expired, the would-be volunteer (or others) are empowered to charter a new working group for the project, without fear of overstepping invisible boundaries or stepping on the toes of someone who once owned the project long ago.

=== The Expiration of a Working Group Is Essential ===

Often, someone has the drive and energy to work on a specific initiative, but over time, that zeal fades and other aspects of their life take priority, and three, five, or ten years down the road, when someone exclaims, “I want to help with [specific initiative]! Who do I talk to?,” that initiative is now in a state of limbo.

The natural response is, “So-and-so worked on this before. Talk to them.” However, sometimes //so-and-so// can’t be reached, or they still feel a sense of responsibility and obligation to the initiative, so they might respond, “Sure. Let’s talk. I have a bunch of ideas I didn’t have time for. Let me put my notes together,” but then the conversations never happen, and the new volunteer loses interest and excitement and moves on to other things.

This is a kind of [[https://en.wikipedia.org/wiki/Founder's_syndrome|founder’s syndrome]] or gatekeeper problem, and it is usually not malicious, nor is it an intentional effort to prevent participation. It happens in the PHP Project because there are no structures or processes to designate or change owners of an initiative when the previous owner is no longer active or has lost interest in that particular thing.

When a Working Group expires, it allows the community to re-start initiatives with new owners, without fear of stepping on anyone’s toes or hurting their feelings. This becomes the expectation of both those creating the Working Group and those who would later re-charter an earlier Working Group.

=== Chartering Via PHP RFC ===

Since chartering and re-chartering a Working Group must go through the PHP RFC process, there are many benefits that avoid the drawbacks associated with hierarchical, top-down governance structures:

  * No single person or committee has the authority to create a Working Group.
  * The Community has the opportunity to provide feedback and shape the scope, structure, and timeline of the Working Group.
  * Earlier owners of initiatives have the opportunity to voice opinions, raise issues, share knowledge, or volunteer to help with the new group
  * Voters can decide which initiatives are important to the PHP Project by accepting or rejecting Working Group RFCs.
  * Rejected Working Group proposals may be resurrected following the PHP RFC process.

Likewise, a Working Group may be dissolved through the PHP RFC process prior to its expiration if the Community feels the Working Group has achieved its goals, failed to achieve its goals, or gone dormant. Again, since this follows the PHP RFC process, no single person or committee has the authority to dissolve a Working Group, and dissolving a group provides an opportunity for Community feedback and input from the Working Group members.

==== Prior Art ====

=== Python Software Foundation ===

The [[https://www.python.org/psf/bylaws/|Python Software Foundation bylaws]] define the process for creating working groups within the Python community. Any member of the PSF may propose a working group, but the Board has the sole authority to approve or dissolve working groups.

Some of the [[https://www.python.org/psf/workgroups/|active working groups]] for Python include:

  * Infrastructure
  * Education & Outreach
  * Diversity and Inclusion
  * Code of Conduct
  * Packaging

=== Rust ===

Rust established a leadership council and a set of initial top-level teams by RFC (see [[https://rust-lang.github.io/rfcs/3392-leadership-council.html#top-level-teams|Rust RFC #3392]]). The leadership council has the authority to propose new top-level teams, and it appears these must be approved through the Rust RFC process (though the only top-level teams they currently have are the ones created by the aforementioned RFC).

Rust additionally has the concept of working groups, or “project groups,” that are created through consensus of Rust teams (e.g., through RFCs). This is described in [[https://rust-lang.github.io/rfcs/2856-project-groups.html|Rust RFC #2856]].

Some of the [[https://www.rust-lang.org/governance|top-level teams and working groups]] for Rust include:

  * Dev Tools
  * Infrastructure
  * Moderation
  * CLI
  * Security Response
  * Triage

=== Node.js ===

Node.js has a [[https://github.com/nodejs/TSC/blob/main/TSC-Charter.md|technical steering committee]] (TSC) that has the authority to create working groups. Working groups must already be active, performing the work of the working group, before drafting a charter for ratification by the TSC. This process is described in [[https://github.com/nodejs/TSC/blob/main/WORKING_GROUPS.md|Node.js Core Working Groups]].

Some of the [[https://github.com/nodejs/TSC/blob/main/WORKING_GROUPS.md#current-working-groups|current working groups]] for Node.js include:

  * Streams
  * Build
  * Release
  * Package Maintenance

=== PHP-FIG ===

A bit closer to home, the PHP-FIG bylaws define [[https://www.php-fig.org/bylaws/mission-and-structure/#working-groups|creation and management of working groups]] within their organization. These working groups are usually created for the purpose of drafting and proposing PSRs and PERs.

==== Examples ====

=== Communications ===

One possible use-case is the formation of a Communications Working Group. The PHP Project has never had a dedicated communications team, though we have a variety of communications channels that could benefit from coordinated planning and a well-defined “brand voice.”

=== Infrastructure ===

A common in-joke among PHP internals members is that, for developers who maintain one of the most popular web programming languages, the PHP Project isn’t very good at maintaining infrastructure. The truth is that we’re not very good at coordinating and focusing volunteer efforts for infrastructure—plenty of folks have expressed a desire to help with infrastructure, but they are always tripped up by the “Who do I talk to?” question. An Infrastructure Working Group would solve this problem.

=== Security ===

In recent years, the PHP Project has significantly improved its channels and processes around reporting and disclosure of vulnerabilities. Once reported, however, the internal processes aren’t well-known or well-defined; there is often even confusion among release managers regarding security patches, and this should not be the case. A Security Working Group would help to bring more transparency and definition to the PHP Project’s security practices, as well as reduce the burden on the few people who currently oversee this process.

=== Triage ===

One great way for new volunteers to get involved in an open source project is through verifying and triaging bug reports, but the PHP Project does not currently have a program for this. Creating a Triage Working Group would help define such a program and provide a way for new, eager volunteers to jump in and help the PHP Project right away.

=== PHP Technical Committee ===

In 2023, Jakub Zelenka and Larry Garfield proposed a [[https://wiki.php.net/rfc/php_technical_committee|PHP Technical Committee]], which was declined by the PHP Project voters.

This Working Group proposal is not an attempt to resurrect the PHP Technical Committee proposal. However, if this Working Group proposal passes, it would be possible to propose a new, chartered Technical Working Group with similar goals and responsibilities as defined in the original Technical Committee proposal.

==== Implementation ====

After the project is implemented, this section should contain

  * the version(s) it was merged into
  * a link to the git commit(s)
  * a link to the PHP manual entry for the feature
  * a link to the language specification section (if any)

==== References ====

Links to external references, discussions or RFCs

==== Rejected Features ====

Keep this updated with features that were discussed on the mail lists.
Page Tools
