p5.js Shared Responsibility Committee

1. Amy B. Woodman (PF team, since Sep 16, 2025)
2. Dave Pagurek (p5.js community, since Sep 16, 2025)
3. Kenneth Lim (p5.js community, since Sep 16, 2025)
4. Kit Kuksenok (chairperson, since Sep 16, 2025)
5. Xin Xin (PF team, since Sep 16, 2025)

Guideline v1.3

The p5.js Shared Responsibility Committee is a joint decision-making body with members from Processing Foundation and the p5.js contributor community, accountable to the wider community through transparent processes.

1. HOW DO WE USE THIS DOCUMENT?

(1) This is a guideline on how to make collective decisions about p5.js, focusing on our core shared responsibility: increasing access, in accordance with the mission of PF as stated in 1(3); also referred to as the CORE COMMITMENT TO INCREASE ACCESS as stated in 1(4). Every person on this committee affirms this as the main goal of the committee in all its activities.

(2) Governance is the collective management of shared resources and costs. The Processing Foundation (PF) and p5.js share many resources: volunteer effort and time, funding, staff, operational expenses, the goodwill of partner organizations and communities, social capital, and various community-created software artifacts. Though the values of PF as an organization and p5.js as a software and community project are aligned, the resource needs can differ; the costs of different initiatives are also not distributed equally. We, the members of the p5.js Shared Responsibility Committee (SRC), manage our shared resources and costs through deliberative consensus with a public record that balances representation of PF and p5.js interests.

(3) PF Mission: Our mission is to promote software learning within the arts, artistic learning within technology-related fields, and to celebrate the diverse communities that make these fields vibrant, liberatory, and innovative.

(4) p5.js Access Statement (as adopted by the 2019 Contributors Conference): Increasing access is not focused on expanding the raw number of people in the p5.js community. It is a continued commitment to making p5.js available to and approachable for people who have been excluded from the p5.js community as a consequence of structural oppression. This commitment extends to the tools and platforms p5.js offers. It also includes the makeup, decision-making, and actions of p5.js leadership. We resist a technological culture of speed, growth, and competition. We prioritize intentionality, slowness, accommodation, and accountability as acts of collective care. Access here means making p5.js equitable for:

• People who speak languages other than English
• Black, Indigenous, People of Color, and people of marginalized ethnicities
• Lesbian, gay, bisexual, queer, questioning, pansexual, and asexual people
• Trans, genderfluid, agender, intersex, and two-spirit people, women, and others with marginalized genders
• People who are blind, d/Deaf or hard of hearing, disabled/have a disability, neurodivergent, and chronically ill
• People who have lower income, or lack access to financial or cultural capital
• People with little or no prior experience in open source and creative coding
• People from diverse educational backgrounds
• People across all age groups, including children and elders
• People with a variety of technological skill, tools, and internet access
• People from diverse religious backgrounds
• Other people who are systematically excluded and historically underrepresented
• And all intersections thereof

We recognize the complexity of the terms used to describe our respective identities. Language is nuanced, evolving, and contested. This is not an exhaustive list. We provide an attempt to name and be accountable to our commitments and to the diverse needs of the p5.js community.

(5) The access statement in 1(4) is the source of truth that online versions should reflect. Therefore, the access statement can be amended through the same procedure as any other part of this document. The mission of the Processing Foundation in 1(3) cannot be amended by the p5.js SRC in any way.

2. ROLES & RESPONSIBILITIES

(1) The committee is 5-10 people, including a CHAIRPERSON, balancing p5.js and PF interests:

• 2-5 p5.js community members (excluding PF team/board members) who represent the needs of p5.js as a software project and community.
• 2-5 PF team/board members (not counting the p5.js Project Lead) who represents the needs of PF as an organization.

(2) What does every committee member do? Individual rights and responsibilities:

• Every committee member should bring up any situations where it’s not clear whether something meets the commitment of p5.js to INCREASE ACCESS, but should be determined: for example, a new initiative or proposed project.

• Every committee member can bring a motion to the floor. This includes a motion of no confidence (immediate removal of the Chair from the Committee), or motions to add or remove members of the committee.

• Every committee member can share any “public note” in the decision record in any way they want. This can include: (1) the explanation in the public note, and (2) the date. This can NOT include voting details or internal notes that may contain sensitive information.

• Every committee member can step down at any time unilaterally with immediate effect. All committee members are encouraged to keep their terms to no longer than 3 years, but this is not a strict guideline, and depends on the circumstances.

(3) What does the chairperson do? Leadership rights and responsibilities:

• The p5.js Project Lead is the default CHAIRPERSON, but the committee can vote another person to hold this position, either temporarily or permanently.

• The chairperson holds all the same rights and responsibilities as other members, in addition to a few others:

• The chairperson sets the agenda: scheduling the topics on the group’s agenda and calendar, and communicating about them ahead of meetings. As any other member of the committee, they can add topics to discuss.

• If there’s a topic that is very challenging to find an agreement about, it is the chairperson’s responsibility to find advisor(s) or mediator(s) in the community, or other solutions to resolve the challenges.

• External advisors or mediators are invited, non-permanent members. Timing and compensation is determined on a case-by-case basis as part of the motion to invite them. They contribute to DELIBERATION and voting; importantly, they help the committee resolve stalemates or fill gaps of understanding or uncertainty.

• The chairperson is responsible for recording motion and outcome, and facilitating DELIBERATION by sharing materials to consider at least 1 week / 7 days in advance of any motion related to those materials. If there are logistical challenges, it is the chairperson’s job to notice and proactively improve scheduling.

• The chairperson initiates drafting of the public decision record note, and ensures that all voting members have at least 1 day to review the note. The note must be as detailed as possible, without revealing confidential or private information.

• If a NO-CONFIDENCE motion passes, the chair is removed from the chairperson role and/or the committee immediately. If they are the p5.js Project Lead, their employment or job tasks are not affected - the decision is strictly about their role in the p5.js Shared Responsibility Committee decisionmaking.

(4) How can a contributor or PF team/board member become part of the p5.js SRC?

New members are added by closed nomination based on extensive established contribution to the p5.js community. Each SRC member nominates up to 3 people for internal review, prior to contacting the people. All current members of the SRC provide their nomination notes. Ranking by priority (based on collective subjective estimation of the recency and relevance of the nominee’s activities), the SRC reaches out to the top-ranked nominees in order, until there can be 5 interviews with available nominees covering how they would reflect inclusion and access in their role. Interviews are either recorded or attended by all members of the SRC. Based on deliberation, the open seats are filled in a way that best enables the SRC as a whole to act on the core values of inclusion and access.

(5) How can a contributor or PF team/board member become part of the p5.js SRC? New members are added by closed nomination based on extensive established contribution to the p5.js community. Each SRC member nominates up to 3 people for internal review, prior to contacting the people. All current members of the SRC provide their nomination notes. Ranking by priority (based on collective subjective estimation of the recency and relevance of the nominee’s activities), the SRC reaches out to the top-ranked nominees in order, until there can be 5 interviews with available nominees covering how they would reflect inclusion and access in their role. Interviews are either recorded or attended by all members of the SRC. Based on deliberation, the open seats are filled in a way that best enables the SRC as a whole to act on the core values of inclusion and access.

3. DECISION PROCESS

The p5.js SRC is a transparent body for making decisions. Therefore, all decisions require QUORUM and CONSENSUS and are RECORDED.

(1) QUORUM

Minimum 50% members present, including at least 2 from the PF team/board, and at least 2 from the p5.js community (not inclusive of PF team and board members)

This can mean different things in a synchronous meeting or an asynchronous thread:

In a synchronous meeting, a motion is brought verbally and pasted into the shared confidential document, and votes are cast in that document. By default, all votes are asynchronous, and cast in between regular deliberation meetings where motions can be tabled, clarified, and revised as needed.

In an asynchronous thread, a motion is sent over email. The decision is final when (1) 100% committee members respond with votes OR (2) 1 week / 7 days pass AND a quorum (at least half) amount of votes are cast.

(2) CONSENSUS

Voting yes/no/abstain. Not anonymous. No voting in absentia: members must be present (synchronous) or personally respond (asynchronous). No proxy or pre-submitted votes.

Consensus: minimum 50% yes & no objections. Every joint committee member has veto power. E.g.:

• Not consensus: 1 yes + 3 abstentions; or 4 yes + 1 no
• Consensus: 2 yes + 1 abstain

Abstention counts toward quorum - but recusal does NOT count toward quorum. To abstain is to vote, but not cast either yes or no. To recuse oneself is to not vote at all, such as because of a conflict of interest. Sample conflicts of interest where committee members should recuse themselves and NOT vote:

• representing both p5.js and PF in a matter where there’s very different goals/needs/considerations
• significant personal connection to someone or something being discussed - including motions affecting one’s own compensation or removal from the committee

(3) RECORDED in a public document of all historical decisions.

This is separate from the procedures document, and is shared publicly in the p5.js-src repository.

Committee membership (but NOT attendance/voting) is also public. The purpose is to balance transparency and confidentiality: a final decision is something the committee makes as a whole.

Because votes are cast either in the confidential document or over email, the votes and comments are accessible to current members of the committee. This does not include PF team members outside the committee. When new members are added or removed, a new confidential document is created, to maintain confidentiality of past deliberation.

(4) CONFLICT OF INTEREST

Other than recusal in relevant situations, all members of the SRC are required to annually sign the most current Processing Foundation Conflict of Interest Policy document. The committee can propose a different mechanism to address conflicts of interest, but amendments to 3(4) must have the additional approval of the Processing Foundation board, in accordance with 6(3).

(5) BOARD APPROVAL

Only the following decisions require Processing Foundation board approval:

• Amendments to the following parts of this guideline:
  • Subsection 3.5
  • Section 5 in its entirety, which describes the relationship between PF and SRC
  • Section 6 in its entirety, which describes the procedure for changing SRC scope

Board approval may be granted using the process of the PF bylaws. If the SRC is initiating a change that requires PF board approval, PF board is responsible for responding within 90 days with a decision (accept, reject, or modify).

In any conflict between an SRC decision and a PF board decision, PF board authority takes precedence. The only exception is the matters of separation, described in Section 6.

4. HOW DO WE DETERMINE WHAT FALLS WITHIN THE SRC’S SCOPE?

(1) Our core joint responsibility is INCREASING ACCESS. Any member can raise any topic related to the p5.js software project(s) and either the Processing Foundation Mission 1(3) or the Access Statement 1(4). When it is unclear whether a topic falls within shared responsibility, any member can bring it to the committee for deliberation.

(2) New work, including software changes or public programs, is examined through 2-week async DELIBERATION: commenting on materials to determine how the goal of increasing access is or could be met; and subsequent formal decision. It is the responsibility of the initiator of a major change to software or public programs to share relevant information with the SRC as early as possible. All members must treat all topics as CONFIDENTIAL, unless explicitly stated otherwise. If unsure whether a change is major enough to share, assume that it is.

(3) Fiduciary and administrative responsibilities related to grants and external funding are a shared responsibility, because it likely affects ACCESS. In practice, members of the p5.js SRC are partners on grants that Processing Foundation applies for, or at least made aware of ongoing application processing. At minimum, this means the Processing Foundation is responsible for including someone on the committee (such as the p5.js Project Lead and/or p5.js SRC CHAIRPERSON) in some written capacity during the formative stages prior to application. Prior to submission, the SRC must approve grant budget scope: amount and use of funds to be managed by SRC, and implications for additional work by the SRC or p5.js community, or strategic direction of the SRC, implied by the grant as a whole. Approval must use the standard decision procedure, and cannot be expedited.

(4) Nomination of program recipients and committee appointees is a shared responsibility, because the allocation and disbursement of funds is an important avenue of improving ACCESS to open source contribution, and for including more diverse perspectives in software decision making.

(5) Anything that is brought to the attention of the SRC by any member of the SRC is subject to the decision procedure. The SRC can decide to block, veto, or withdraw its support for an initiative, including a grant application, at any point. It is expected and healthy to have frequent vetos early in the lifecycle of an initiative: this indicates that there is real iteration and improvement. However, if a veto occurs after significant time and energy investment, it can be interpreted as a signal that the deliberation process is not working well, and should be improved.

(6) Some decisions clearly belong to one party. The following are within PF team/board responsibility alone: PF staff matters such as time off, sick leave, benefits, or anything covered by the PF employee handbook; external communications and social media related to p5.js or PF; choosing whether to platform an organization or individual on social media.

(7) The following are within p5.js community responsibility alone: most, if not all, decisions on technical implementation; non-breaking, under-the-hood, and developer-experience software changes; updates to who the p5.js stewards are; blocking GitHub or Discord users due to spam or vandalism.

• Updates to who the p5.js stewards are → p5.js
• GitHub users block due to spam or vandalism concern → p5.js
• Choosing to platform an org (or not to) on social media → PF
• External comms / social media related to p5.js / PF → PF

5. WHAT IS THE RELATIONSHIP BETWEEN P5.JS SRC AND PROCESSING FOUNDATION?

(1) Processing Foundation recognizes the p5.js SRC as a partner decision-making body, not a subordinate one. PF commits to respecting the decision-making process described in this document. PF board members and staff should not unilaterally make decisions that fall within the SRC's defined scope.

(2) The SRC cannot:

• Make legally or financially binding commitments on behalf of PF. For example, if p5.js SRC raises funds, this must be done within the context of PF, and administered through PF using the mechanisms in this document. On its own, the SRC does not have the ability to collect revenue, disburse funds, or pay taxes; consequently, any activities related to funding are done on behalf of and in partnership with PF.
• Override PF board decisions on matters of organizational structure, employment, or legal and financial obligations
• Make decisions about PF staff matters, including compensation, hiring, or termination, except as explicitly noted in Section 3 (e.g., hiring processes where the role includes SRC membership)
• Expand its own scope or authority beyond what is defined in this document without PF board approval, except as part of a separation process

(3) The SRC can:

• Approve or reject proposed work, software changes, or public programs on the basis of increasing access, as described in Section 3.
• Vote to separate from PF, as described in 6 below.

(4) PF cannot:

• Override an SRC decision on matters that fall within the SRC's defined scope, except as described in 6.3 below; appeals follow the process in Section 3
• Appoint or remove SRC community members (non-PF seats) unilaterally; membership changes follow the process in Section 3
• Direct SRC decisions by instructing PF-affiliated members how to vote, or otherwise tampering with the SRC deliberative or decision-making process
• Alter the scope or authority of the SRC without a formal amendment process that requires both PF board approval and SRC consensus
• Prevent the SRC from initiating a separation process as described in Section 5(5)

(5) PF can:

• Override an SRC decision in exceptional circumstances: where it conflicts with PF's legal obligations, fiduciary responsibilities, or bylaws. PF must provide a written explanation to the full SRC within 7 days of doing so
• Dissolve the SRC in cases of serious governance failure, defined as a pattern of decisions that materially contradict PF's mission or legal standing, but only after a documented process of notice, deliberation, and an opportunity for the SRC to respond, and subject to the shared resource (see: 1(2)) negotiation process described in Section 6
• Decline to fund or resource specific SRC-approved initiatives, with written explanation to the SRC
• Initiate its own separation from the SRC, subject to the same process and thresholds described in Section 6, with the roles of SRC and PF reversed

(6) Disputes between PF and the SRC. If the SRC believes PF has acted outside the limits described in this section, the SRC Chairperson may formally raise the dispute with the PF board in writing. Both parties commit to resolving disputes through good-faith deliberation before any public escalation. If resolution cannot be reached internally, both parties agree to seek external mediation before either party takes unilateral action.

6. SEPARATION

(1) Initiating separation or dissolution. The SRC may vote to separate from PF, or to dissolve. PF may also initiate separation, but not dissolution of SRC as an independent entity. Separation or dissolution are the most significant decisions the SRC can make and therefore require a higher threshold than standard consensus:

• The motion must be raised in writing and shared with both the full SRC and the PF board simultaneously.
• A minimum 90-day deliberation period is required before any vote, during which both parties are encouraged to seek mediation and resolution.
• The vote requires unanimous agreement of all SRC members. PF-affiliated members may participate fully in deliberation, but are compelled to recuse themselves from the final vote, as their institutional relationship to PF constitutes a conflict of interest under Section 3(4).
• A minimum of 4 non-abstaining votes is needed. Abstensions are not sufficient, every non-recused member must cast a yes or no vote, or resign.
• Upon a passing vote, a formal 90-day notice period begins before separation takes effect.
• During the notice period, both parties commit to good-faith negotiation over shared resources, as described in Section 5.

(2) Shared resources in the event of separation. The SRC and PF acknowledge that p5.js and the Processing Foundation share significant resources, and that separation would require careful transition planning. Both parties commit to negotiating the following in good faith during the notice period:

• Stewardship of the p5.js codebase, repositories, and community infrastructure, including "owner" and “admin” access roles on GitHub and any other platform(s) directly relevant to code maintenance
• Disbursement of any active funding, grants, or financial commitments related to p5.js
• Transition of PF staff time and roles connected to p5.js work
• Continuity of community programs, fellowship, and educational initiatives
• Public communications about the separation
• Membership and governance structure of the SRC following the separation
• Handover to a new administrative entity for p5.js SRC to be able to act as an independent fiscally responsible organization, if applicable

(3) Possible outcomes. At the end of the notice period, one of three outcomes applies;

• A: Successful separation. The SRC and PF reach agreement on all shared resources. Separation takes effect on the agreed date. The SRC continues as an independent body, with public support by PF that the separation was mutual. Sections 3(5) and 3(6) no longer apply. Those SRC members with PF affiliation, by default, are welcome to stay as volunteers or resign.
• B: Withdrawal of the separation motion. At any point during the notice period, the SRC may vote to withdraw the separation motion. This vote requires consensus. The committee returns to normal operations.
• C: Withdrawal due to PF negligence. No agreement on shared resources because of a clearly documented inability or unwillingness by PF to provide documents or take actions in a timely manner (acknowledging a request effectively within 90 days) that would be required to investigate or implement the separation. In this case, the SRC is entitled to publish any documented part of the deliberation process, if they decide it is needed for community accountability. This vote requires consensus. Everyone involved should be aware of this as a possibility and clearly exclude any confidential data from documentation, or at minimum mark it so it can be effectively excluded at publication.
• D: Dissolution due to SRC negligence. No agreement on shared resources because of a clearly documented inability or unwillingness by SRC to provide documents or take actions in a timely manner (acknowledging a request effectively within 90 days) that would be required to investigate or implement the separation. In this case, the standing SRC is dissolved, with PF taking the responsibility to invite comment from the p5.js community on whether the SRC body should be reinstated, and if so, how it needs to be changed. PF must provide a public announcement and initiate a feedback mechanism within 90 days of dissolution. For example, if SRC becomes significantly non-responsive during handover of fiscal or administrative tasks, then the outcome can be dissolution. During this period, PF is responsible for p5.js decisions that would normally fall to SRC.

(4) What the SRC does following separation is solely within the SRC's authority. Subsections 1(3), 3(5), and 3(6) would no longer apply.

Glossary

• CHAIRPERSON: a member of the committee with some additional responsibilities, as described in section 2
• CORE COMMITMENT TO INCREASE ACCESS: described in 1(4)
• CONFIDENTIAL: SRC scope includes budget allocation and distribution, complex code of conduct violation cases, or other situations where identifying information may come up in discussion. For this reason, the meetings and any related notes are closed.
• DELIBERATION: “a process of thoughtfully exchanging and weighing options, for example prior to voting.”- Wikipedia
• “New work” / “Major change” is left intentionally open-ended in 4(2); this subsection also suggests: if unsure whether a change is major enough to share, assume that it is.
• Motion/vote of NO CONFIDENCE: “In a deliberative assembly, a motion of no confidence is a motion declaring that a government or an officer, typically a government executive, is not fit to hold office. A vote on such a motion is a vote of no confidence; the corresponding inverses are a motion and vote of confidence.” -Wikipedia In the case of the SRC, if the CHAIRPERSON neglects their responsibilities, the other members can vote to remove them from the position of leadership, as described in 2(4).
• Processing Foundation (PF) bylaws
• PF team/board members, also referred to as PF-affiliated members, are members of the SRC who are on the Processing Foundation board or part of the Processing Foundation staff.
• Public note: a summary of a decision or discussion, appearing in the decision record
• Veto: “power to unilaterally stop an official action.” -Wikipedia