Skip to content

processing/p5.js-src

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

4 Commits
 
 
 
 

Repository files navigation

p5.js Shared Responsibility Committee

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

Guideline v1.1

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. 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 manage our shared resources and costs through deliberative consensus with a public record that balances representation of PF and p5.js interests.

(3) This document can be changed anytime, using the decision method it describes. The constitution can also be dissolved, if all members agree.

2. WHO MAKES DECISIONS AND HOW?

(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 uncertianty.

  • 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.

  • 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.

3. WHAT IS A DECISION AND WHY DOES THAT MATTER?

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 chat, and votes are cast over chat.

In an asynchronous thread, a motion is sent over both email and Discord. 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 (sync) or personally respond (async). 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 document of decisions for that year.

This is separate from the procedures document, which may be more widely shared / public. Committee membership (but NOT attendance/voting) is public. The purpose is to balance transparency and confidentiality: a final decision is something the committee makes as a whole.

The document of decisions NOT public, but accessible (read or edit) to current members of the committees. This does not include PF team members outside the committee. When new members are added or removed, there’s a new document. This record clearly indicates internal and public notes, e.g.:

TOPIC & OUTCOME INTERNAL/CONFIDENTIAL PUBLICLY SHAREABLE
PersonC moves to adopt amendments ___ to the procedure ___. ❌ Denied YYYY-MM-DD Yes: X, Y, Z. No: PersonB (with some internal notes). Abstain: PersonC Because of __, we didn’t change our __ procedure, so we will continue to ___.
PersonY moves to suspend/unsuspend user ___? ✅ Passed YYYY-MM-DD Yes: PersonX, PersonY, PersonB, PersonC. Abstain: PersonZ No public statement due to confidentiality.
PersonA moves to ___? ❓ Too many recusals / abstentions: seek ext. advisor(s) Yes: X. Abstain: Z, Y. Recused: A, B, C, D In order to help us understand how to ____, we’ll be looking for external advice from ___.

EXAMPLES OF TOPICS THAT ARE - OR ARE NOT - OUR SHARED RESPONSIBILITY

What is the committee’s scope? Our core joint responsibility is INCREASING ACCESS, defined in the Access Statement. Any member can raise topics related to this statement, or suggest updating the statement, and is encouraged to actively seek gaps in awareness and room for improvement.

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, such as:

  • “Proposing to recognize that ___ increases access for ____ to ___, by ____”
  • “Generally prioritize work X over work Y, because it prioritizes ____ access for ___”
  • “Change scope of work X in ___ ways to prioritize ____ access for ___.”

This is then deliberated on (to work out the details), and voted on (to approve and adopt, or reject and edit/iterate in the future)

Other examples, based on prior decisions, of things that ARE SHARED RESPONSIBILITY:

  • Joint committee membership: “Appoint ____ to the committee,” “Remove ___ from the committee”
  • Hiring process, when the job includes membership on this committee, including the p5.js Project Fellow/Lead
  • Changes in funding for p5.js work: temporary contract scope or contractors

Examples of topics that are NOT shared responsibility, and are specifically within PF team/board responsibility: PF staff matters - such as time off, sick leave, benefits, or anything covered by PF employee handbook

Examples of topics that are NOT shared responsibility, and are specifically within p5.js community responsibility: Most, if not all, decisions on technical implementation

Software changes are sometimes a shared responsibility:

  • Website materials connected to PF programs (fellowship, sketches open calls, educational resources, etc) → PF is responsible
  • Non-breaking, “under-the-hood,” and developer-experience changes → p5.js community is responsible
  • Significant technical changes (including breaking changes or major new features), or changes that significantly alter the course of beginner experience → shared responsibility PF can help facilitate contributor feedback from non-GH users
  • Major campaigns to invite contributors (for example, the GSoC projects list) → shared responsibility PF runs / participates in programs like GSoC

Making decisions related to community management is sometimes a shared responsibility:

  • User suspension in community spaces → shared responsibility
  • Code of Conduct revision → shared responsibility
  • Changes to p5.js stewardship process → shared responsibility
  • 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

About

p5.js Shared Responsibility Committee

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published