Community Summit Discussion Notes: Unifying development tooling for contribution

From the schedule session:

Today, the local development tooling for contribution to WordPress is fragmented. Contributors use tools such as VVV/Vagrant, Docker, and Playground, but each have limitations and may not be endorsed for contributions. Additionally, some tools require specific set ups, making it challenging for contributors to get started. This discussion will explore how we can unify tooling to provide clarity around recommended tooling and process for contributors.

Facilitator: Aaron Jorbin (@jorbin)

Notetaker 1: Weston Ruter (@westonruter)

Notetaker 2: Emma Sophie Young (@emmaht)

Continue reading

#summit, #summit-2023

Community Summit Discussion Notes: What is the criteria for delaying the upgrade of foundational tech, and what triggers reconsideration?

From the schedule session:

From time to time, it’s necessary to delay adoption of newer versions of our underlying technology, either because our software isn’t yet fully compatible or we otherwise cannot recommend the use of the new technology. This is an appropriate measure to take when we are thinking through the promises we make to our users, but what should be the acceptance criteria for reconsidering a delay?

Facilitator: Marius L. J. (@clorith)

Notetaker: Weston Ruter (@westonruter)

Continue reading

#summit, #summit-2023

Community Summit Discussion Notes: Exploring how the Accessibility Team can support Making WordPress teams

From the session schedule:

The AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) Team would like to explore how it can become a shared resource and best support Make Teams and the WordPress project as a whole. The current challenges are that this small team struggles to track where they could be helpful across the WordPress project, and they would like a stronger system that allows them to better address requests as a whole team.

Perspectives needed: Current and interested Accessibility Team members, members from other Make Teams who want to collaborate with Make Accessibility.

Facilitator: Joe Dolson (@joedolson)

Notetaker: david wolfpaw (@wolfpaw)

Notetaker: Taco Verdonschot (@tacoverdo)

Raw Notes:

  • we would like to see how we can be a better support for other Make teams, given our extremely limited resources as a small team.
  • We are in total the equivalent of one full-time person of hours, supporting all other teams.
  • The accessibility team proactively reaches out to other teams, and would like to not do that – one of the biggest consumers of team time is trying to reach out and see what they can do. It’s not about doing more, it’s about being more productive.
  • Some other teams would like to switch this around, and see what they can do to proactively reach out to the accessibility team to see what is doable and how they can help. Recognize at what point they should be asking for input to see where they could go wrong with accessibility without proper support and information.
  • The accessibility team could help to identify what things teams should be aware of, and the crucial timing
  • For other teams: what ways do you interact cross-team that are working already, whether they are formal collaborations or are ad-hoc?
  • Successful is always a work in progress. For example, we have help with accessibility with one point person. It is very helpful, but it would be better to have more than one. Having checkpoints on when we could use extra feedback, providing a feedback cycle. Acknowledging as a team that nothing is set in stone, even if we’ve already started moving forward.
  • One example of the crossover work with the documentation team is that someone keeps an eye on what is going on in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ to know what Documentation needs to be updated. Similarly, Learning looks to Marketing and Documentation to see what is coming up and knowing what
  • Each team should have an accessibility lead, who can liaise with the cross-team Accessibility Team. There is a lack of education for teams to know what things they are doing are not accessible. Having a champion of accessibility on each team would make it easier to have cross-team collaboration.
  • Part of the routine, weekly structure of the accessibility team currently is reviewing updates from other teams. It has been hard to get people from other teams to actually do those reports.
  • The Documentation team has someone trawl through pull requests and posts from other teams. It is a fairly intensive project that takes a lot of time to do.
  • Ideally the person for each team has a basic sense of accessibility, even though they are active on another team. What skills do they need, and is that something easily trainable?
  • Some simple things can be easily learned, such as color contrast, font sizing, using extensions that help to manage it, etc would be easy for someone to pick up.
  • Content Creators may have the same questions, and the liaison can give them answers to take some of the burden off of the accessibility team.
  • Working out what a liaison needs will work wildly different based on the team. It could be a process of discovery between those teams. Something within scope of the accessibility is to have a one-on-one with the liaison, have a discussion, document it, and publish it.
  • Real world accessibility at events has other needs, but it is within the team purview. There is a P2P2 P2 or O2 is the term people use to refer to the Make WordPress blog. It can be found at https://make.wordpress.org/. channel and they are working on documenting to setup principles and documentation that can be referred to for every WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more.. Documents will be published from the Community Team.
  • By the Accessibility Team doing outreach to other teams it can be seen as critical, as opposed to being helpful. The sooner that the team can get involved, the more that it can be collaborative.
  • There is worry that the Accessibility Team is seen as a blocker for growth. It is preferable to have others reach out for feedback, as opposed to being reached out to after things have been published.
  • Other teams don’t want to be badgering the Accessibility Team all of the time, so there’s a problem there. It has been tricky to get feedback on some in-progress things. Part of the wordpress.org redesign has been trying to get pages live to get feedback and update, but it has been perceived as being done.
  • There could be some sort of flag that pages need review still. The challenge with having a flag is that it will be perceived as a blocker; everything is done except for that review.
  • Documentation is confusingly not responsible for all documentation. For instance for handbooks. But the documentation team can provide assistance. By helping the Playground Team it has made it more known throughout the project what needs to be done for accessibility.
  • All of the teams could have templates of how to work with cross-teams for things like accessibility.
  • Working with the Training Team, trying to work with the Accessibility Team has been difficult.
  • There are two questions: what are the difficulties with onboarding people, and what are the difficulties with retaining people. We have so many needs that onboarding is hard to do.
  • One of the biggest problems with onboarding is frustration and pushback in trying to get things done for Accessibility.
  • There is a concern as to what legal fears exist for attaching our names to teams for doing things relating to Accessibility. For instance, there are overlay companies who have been doing legal battles, and are highly litigious and have a lot of money. These tools do not really work and people have been sued or threatened with lawsuits. Adrian Roselli is being sued currently as a notable example
  • If there was a way to obtain support from the WordPress Foundation that there would be support concerning frivolous lawsuits. But that would be a difficult ask to have and unlikely to happen.
  • The individual teams could work better at onboarding new people to do accessibility with more redundancy and scaling. This could be done with
  • The looping of people together from various teams sounds like it would be a good place for a Working Group. This would go with the most pressing accessibility concerns to start, and then turning that into a Working Group that would go through getting a liaison for the team, working with Documentation, creating onboarding, having the documentation and onboarding live on Learn WordPress, having things where people can step in, do training, and be qualified.
  • Individuals will not have the confidence to step into a role of being a liaison without having some formalized training that qualifies them.
  • There should be some feedback on how people got interested in being involved in the Accessibility Team from a different team, to determine how to best make people liaisons. The Community Team reached out to see how they could best facilitate to make WordCamp US 2023 more accessible for instance. Community Team has the risk that their accessibility mistakes are often more public, with more people talking about them.
  • The Accessibility Team deserves credit for a tone shift into, “How can we help other teams do better?” as opposed to pointing out what has been done wrong.
  • An issue is when the Accessibility Team provides feedback, and the feedback is not implemented. When issues are highlighted and no one wants to do anything about it. A reason to stop things from moving forward beyond development/merge is that once it is launched, it is hard to get things resolved for accessibility. Maybe for visual or functionality, but not for accessibility.
  • People on teams do too much to move new features apart, making it harder
  • How people can help: having a pause window on pushing new features up, but making it better worded that it will sound like . It is hard to see which things are actually moving forward versus which features are just experimental and won’t ever go anywhere. If everything in progress, even basic experimental
  • There are security audits that happen automatically that will stop things from moving forward. Why are there not automated and manual checks for accessibility that are not blockers for things moving forward? There are some incredibly basic problems that are not addressed before features go out for review or even to publish.
  • Automated testing does have its place. Some of the issues are so basic that the browser automated accessibiilty testing would catch. It would be worthwhile to eliminate a base set of issues by starting to incorporate automated testing, but make it clear that passing that testing does not make it accessible, just saves some time.
  • Guternberg, most of the time, is good with micro issues for accessibility interactions. But is on the macro issues that need help. Getting rid of having to look for micro issues will really help.
  • The hard part is setting up infrastructure for testing, not writing actual tests
  • There is not yet something in Training for general accessibility testing. There is an open issue for something to be vetted.
  • The 5 for the Future discussion talked about having companies take on specific projects, which could be a place for a company with focus on accessibility that would be willing to take on this task.
  • Having a conversation with MetaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. and Documentation team to work out how to be a liaison for those teams would be a good start. Being able to incorporate more automated testing into Core would help. Teaching people at the best point to reach out to Accessibility Team would help.
  • There should be criteria for if something is flat-out a blocker to something launching on the accessibility level. Similar to how there is for things like security issues.
  • Some of the basic things that could be solved are having things like checklists for the Community Team that will make sure that basics of accessibility team are covered for events, as well as the websites around them. Informing people who are attending what accessibility means for your event and venue, not just ensuring that they are there.
  • A proposal to refer to liaisons as “allies” to the Accessibility Team, ensuring that there will be someone embedded in that specific team that will champion their needs. This is especially relevant to content-heavy teams, such as learning, documentation, training, marketing.
  • The need for liaisons could be a specific level of knowledge that is siloed that could be solved by people with the specific, focused knowledge working with the people having issues directly.
  • The liaisons and allies don’t have to be one person on each team, but could be a larger number of people to avoid information siloing. It is all coming down, one way or another, to documentation. The Accessibility Team would definitely benefit from help from the Documentation Team.
  • Upcoming legislation that will be more and more strict on accessibility. Informing people about what is coming up: is that something that would be considered as a role for the team, since there is no legal team? The Accessibility Team says no, they are not qualified to provide legal advice and could not be the resource for this.
  • A rewrite is in progress, but has been in progress for two years, of the Accessibility Team page on make.wordpress.org One of the topics for Contributor DayContributor Day Contributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of https://make.wordpress.org/ There are many teams that people can participate in, each with a different focus. https://2017.us.wordcamp.org/contributor-day/ https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/. is what the statement that the team will be about, but also having accessibility statements for the website itself.
  • The commitment to accessibility should be spread across more teams. From a practical standpoint, there is nothing that is, “just the Accessibility Team”. There is always a reason to have subject matter experts, to ensure that different teams do not go in different directions on what we should do.
  • Quite a few teams have people that are cross-team active. Given the low resources for the a11yAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) team, it’s not feasible to have them in all the other teams.
  • A11y team is actively searching for updates from other teams. This is currently happening with a few teams, but not with all of them. 
  • What would a liaison-person need as skillset? Is that easily trainable?
  • Working out what a liaison needs depends on the team. It would be a process of discovery. A possible feasible offer from the a11y team would be to have 1-on-1 with the potential liaisons. 
  • Does the a11y team also extend to in-person events, or is it limited to the WordPress software?
  • Yes, but it’s taking a severe toll on the time available to work on the software. 
  • What are the challenges to onboarding new people to the a11y team?
  • We’re so busy trying to keep up, we don’t have the time to onboard new people. We need people to be coding, we need people to be testing. 
  • What are the challenges to retaining people to the a11y team?
  • People are getting burned out from the pressure and frustration, due to the slow process and severe pushback. The other reason is Matt Mullenweg, who personally offended many people in the a11y community team. 
  • I don’t feel comfortable contributing to the a11y team because of lawsuits happening against a11y experts. 
  • [short explanation of what’s happening to Adrian Roselli] 
  • Can we form a working group that goes through all the other teams to create a resource on what an a11y liaison should be/do? That way we can create a “personalized” course for each team. 
  • One of the challenges is identifying issues that are actually moving forward vs issues that are just experimental and will never go anywhere, and thus don’t need the a11y team’s attention. 
  • Is it possible to automatically check for some of the basic things?
  • Yes, that would be possible as part of a linting process. But it indeed is very basic, because it would still need a check by a person to verify if -for example- naming is done right.
  • Action items
    • Have a conversation with meta and training to find out what a liaison role should look like
    • Have more automated testing
    • Having champions for a11y in different teams

#summit, #summit-2023

Community Summit Discussion Notes: Handling Trust & Safety (“T&S”) in the WordPress ecosystem: content moderation and sensitive content

From the session schedule:

WordPress has many community-led initiatives and directories with user-submitted content, like the Pattern Directory, the Photo Directory, Openverse, Themes, Plugins, and Support Forums. These areas hold user-submitted content, whether text or other media. However, each team has its own methods to evaluate its content, and its own moderation practices. This discussion aims to better understand current practices across teams towards establishing project-wide best practices and clear guidelines that prioritize safety and equitable moderation.

Facilitator: Kathryn Presner (@zoonini)

Notetaker: david wolfpaw (@wolfpaw)

Raw Notes

  • There are areas where users can submit media, and each team has protocols on how people moderate content. What are other teams doing, what can we learn for each other, and what are best practices that we can bring that are safe and equitable.
  • Openverse is a search engine for open sourceOpen Source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. media that is integrated in WordPress as of v6.2 to add content to blogs. It is an aggregator of creative commons licensed content. Openverse is an aggregator, unlike Photos team, where people upload things specifically
  • Having aggregated content makes it so that things are not consistent between platforms that are aggregated from. Do we use our own guidelines on how we moderate content that comes in.
  • Are there trust and safety courses on WordPress Learn? It is doubtful since it is a niche area of needs.
  • The community team has resources for de-escalation but there are not a lot specific to our community
  • Are there ways to report content from within WordPress – yes, there is in GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/, but what is the mechanism that is triggered when
  • Openverse comes across content that is sensitive in searches and reporting, and they are working on mechanisms to handle this
  • A lot of people who use Openverse are using it in an education context
  • It’s a difficult problem because you cannot apply a one-size-fits approach to moderation
  • If you pt that to one group of people, no one has all insight to things that are offensive in some cultures but not offensive to others.
  • There are legal restrictions in some countries that go against legal requirements in other countries
  • Openverse is in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., so the software is from a foundation based in the US, so do we have to legally comply with what other countries do?
  • Private companies like WordPress.com abide by US law when it comes to trust and safety issues
  • Sometimes outsourcing happens for moderation, and that includes for different cultures
  • If a country decides to blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. Openverse for not meeting their requirements, it is up to a website owner to determine to manage that accordingly when making their website
  • Some people say, “keep politics out of tech”, but there have to be defaults on some things, and we don’t know how to reach consensus on it, drawing a line in the sand as the WordPress project. It’s good to have options, but most people don’t change defaults.
  • Support has a bunch of things that could be useful for other teams. One thing is that every forum topic has a report this topic button, and people have to choose why to report a topic
  • previously you had to add “mod-look” to a forum to get into the queue of support
  • Content that can be marked as unsafe for everyone,
  • We can flag folks for mod-watch in forums, and they cannot post or make topics without being manually approved by moderators. Volunteers go through that queue to approve. This can be automated depending on what people type, such as “security vulnerability”, or spam checks on their profile and forum replies
  • Things like mature content are also not indexed from the forums so when you search for support it won’t come up top
  • There’s no prioritization on the queue by topic, just by chronological time of adding
  • People can also be moderated manually, with a flag on their posts to be pre-moderated
  • Notes can be left to review about users, and this can be used to unflag people
  • Teams like Support and Openverse could share their T&S guidelines with other teams, though a lot of them are case-specific.
  • We need to have language about calling something sensitive, and then the reasons that they are called sensitive, such as things that are “mature” or not.
  • Basing things on a blocklist can have cultural issues, like names and words that are commonplace or not sensitive in one location but are in others. For instance, the use of “nonce” in American tech culture, versus British English.
  • The sensitive terms list of Openverse is public as file for indexing and reference
  • We don’t obfuscate all content, but you can set limits for what is returned when you search for sensitive content. For instance, blurring search results for images of sensitive content unless you opt not to. We don’t want to stop what people search for, but providing consent on what you will see when you do a search. If you are looking for sensitive content and is relevant we want to acknowledge that while making the platform safe to use
  • Various different categories of sources for content to aggregate to OpenVverse, there are different levels of trust on content. So like in Gutenberg we don’t return searches for Flickr and Wikimedia, which are more akin to social media. They are still available on Openverse, but not in this context
  • In the theme and pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party space, there are some trust and safety issues that arise. For instance a plugin that was blown up and escalated overnight that was in support of the Russian war. It was a bigger deal than it might have been because there was no formal process for it.
  • Is there some form of record keeping of trust and safety related for when there are problems
  • The people who are most equipped to handle subtle problems with moderation are not always supported with things like mental health, and have to deal with the worst things
  • Doing trust and safety and moderation in a community level is quite different from doing it from a corporate level
  • There are opportunities to build a network to support people at a community level for mental health
  • Is there room for a Trust and Safety Make team that is cross-funtional with other Make teams on ensuring that they have support for this topic.
  • We would like to have someone pursue a cross-functional Make team, and getting sponsored volunteers for moderation.

#summit, #summit-2023

Community Summit Discussion Notes: Addressing backwards compatibility in Gutenberg

From the schedule session:

This discussion aims to explore the challenge of backwards compatibility in JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. and PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. https://www.php.net/manual/en/preface.php. APIs from the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ project into WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. Currently, there is little clarity around maintenance of backward compatibility across the project, resulting in confusion for developers and performance issues. There are two focus areas:

  1. Depreciating officially stable APIs that have been replaced
  2. Depreciating unstable, experimental, or internal APIs that have been shipped in WordPress.

Perspectives needed: Senior WordPress Core contributorsCore Contributors Core contributors are those who have worked on a release of WordPress, by creating the functions or finding and patching bugs. These contributions are done through Trac. https://core.trac.wordpress.org./committers with deep knowledge of past lessons learned around backwards compatibility, Gutenberg contributors with working knowledge around processes and decision making.

Facilitator: Marius L. J. (@clorith)

Notetaker 1: Weston Ruter (@westonruter)

Notetaker 2: K. Adam White (@kadamwhite)

Continue reading

#gutenberg, #summit, #summit-2023

Community Summit Discussion Notes: Aligning WordPress Enterprise with WordPress Community

From the schedule session:

In recent years, WordPress has struggled to grow at the enterprise level. At the same time, companies and individuals invested in enterprise could be an immense value-add to the WordPress open sourceOpen Source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. project. This discussion will explore the current friction points between enterprise interests and community interests, and where alignments can be amplified for mutual benefit.

Facilitator: Siobhan McKeown (@siobhan)

Notetaker 1: Weston Ruter (@westonruter)

Notetaker 2: Jon Ang (@kenshino)

Continue reading

#enterprise, #summit, #summit-2023

Community Summit Discussion Notes: Aligning processes and contributions between WordPress Core and Gutenberg

From the schedule session:

WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ currently have different release schedules and velocities, and are managed in two different locations (TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/./SVNSVN Apache Subversion (often abbreviated SVN, after its command name svn) is a software versioning and revision control system. Software developers use Subversion to maintain current and historical versions of files such as source code, web pages, and documentation. Its goal is to be a mostly compatible successor to the widely used Concurrent Versions System (CVS). WordPress core and the wordpress.org released code are all centrally managed through SVN. https://subversion.apache.org/. and GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/). This complicates merging Gutenberg code into Core. For example, it is unclear where modificatons should occur, resulting in version control issues. This discussion hopes to bring clarity to these issues and explore possible processes and solutions.

Perspectives needed: Current and interested Core and Gutenberg contributors, project managers, and team members following the release process.

Facilitator: Jonathan Desrosiers (@desrosj)

Notetaker 1: Daniel Bachhuber (@danielbachhuber)

Notetaker 2: Rebekah Markowitz

Notetaker 3: Sarah Norris (@mikachan)

Continue reading

#summit, #summit-2023

Community Summit Discussion Notes: Accessibility in the WordPress Project

From the schedule session:

How can WordPress adopt an accessible-first approach, and what would this mean for project development and decision-making? This discussion will center on accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) considerations in developing WordPress software and current friction points, and explore possible solutions and practices to incorporate.

Perspectives needed: Current and interested accessibility advocates, people interested in or currently involved in release cycles.

Facilitator: Joe Simpson, Jr (@joesimpsonjr)

Notetaker 1: Weston Ruter (@westonruter)

Notetaker 2: Daniel Bachhuber (@danielbachhuber)

Continue reading

#accessibility, #summit, #summit-2023

Community Summit Role: Taking Stack and Keeping Time

Each Community Summit discussion will have:

  1. One Facilitator
  2. Two Notetakers (read about the Notetaker role)
  3. One Stack Keeper/Time Keeper

Please familiarize yourself with the Stack Keeper/Time Keeper role in advance, so you’re ready to volunteer!

Purpose: The purpose of taking stack is to ensure that all participants’ voices can be heard in the discussion. Otherwise, an individual or a small group of people could easily dominate the discussion and shut out other participants.

The role of Stack Keeper: At the beginning of each discussion, the Facilitator will request a volunteer to be the Stack Keeper. It is the Stack Keeper’s responsibility to structure and order the dialogue. “The Stack” is the order of participants who are speaking. If a participant raises their hand to say something, the Stack Keeper puts them on “Stack.” That is, the Stack Keeper puts their name at the bottom of the stack list. When the person at the top of Stack has finished speaking, the Stack Keeper crosses their names off and announces who the next two participants on stack are. The Stack Keeper should also make sure that people who have spoken before come after folks who have been added to the Stack for the first time.

Thus, the Stack Keeper is the person responsible for identifying who speaks and when. The Stack Keeper must constantly be paying attention and scanning the room to see who wants to speak. In addition to these duties, both the Facilitator and Stack Keeper may also contribute normally to the discussion.

Keeping time: The Stack Keeper is also responsible for keeping time during the discussion. It’s important that the Stack Keeper/Time Keeper let the Facilitator know when it’s time to wind down the discussion and shift to Next Steps and Action Items (at least 5 minutes before the scheduled end-time). This will help avoid an abrupt end to the discussion, and ensure that the group has clearly identified next steps before the discussion concludes.

Community Summit Non-Attribution Guideline

As we prepare for the Community Summit, we’d like to share the important guideline of non-attribution, to ensure productive and open discussions.

While we welcome and encourage you to share the content and insights from our discussion with others, we kindly request that you practice non-attribution. This means that outside the Summit you can discuss the general ideas and themes that arise, but please refrain from directly quoting or attributing specific comments to individual participants.

Our goal is to create a safe, inclusive and collaborative environment where everyone feels encouraged to brainstorm, share their thoughts, and speak their minds. By not attributing comments to specific individuals, we hope to foster a space where participants don’t have to worry about their words being taken out of context or used against them outside of the Summit discussions.

In the spirit of non-attribution, we request the following:

  • Stay Present: We kindly ask that you refrain from posting on social media during Summit discussions. This helps ensure that everyone is actively engaged and present in the moment.
  • Photos: You’re welcome to take photos, but please ensure they align with our non-attribution guideline. This means avoiding photos that tie specific comments or ideas to particular individuals.
  • Recaps & Summaries: You are welcome to share post-event recaps. However, please ensure that these do not attribute specific comments or viewpoints to individual participants.

Thanks for your understanding and cooperation. We’re excited to dive into these discussions together!