From the session page:
A number of teams and their work in the WordPress project currently receive little visibility, but also have high stakes or impact on the health of the WordPress community. Especially in recent years, the contributor pipeline for these teams has faced significant struggles. This discussion will explore how to address the broken pipeline, support the contributors involved, and how to give appropriate appreciation to this difficult work. Examples of teams facing this challenge include Plugins, Support, Security, Incident Response.
Most open-source projects don’t have enough people to do the work that needs doing. Investing time in recognition means we’re building a strong foundation for bringing in more future contributors.
- Which groups tend to feel under-appreciated in the project?
- What are some ways to give more recognition to those teams, both to make them feel more appreciated and also to encourage more people to contribute in those areas?
Publicizing our work and team makeup
- Certain teams (like Support) are more public-facing than some which have good reason to be operating more “secretly” – like Security and the Incident Response Team (IRT). How can we bring to the forefront those more behind-the-scenes teams and celebrate their work more?
- Sometimes we aren’t good about posting our work publicly – very few Make posts from certain teams. Need to keep p2 content fresh to highlight the work we’re all doing.
- Incident Response Team requires a certain level of confidentiality, which can feel at odds with transparency. They try to be transparent about the process and steps, while balancing confidentiality and transparency.
- People drawn to Incident Response team maybe don’t care as much about recognition? Could be more tenure-based recognition.
- Important for community to know who is on certain teams – makes them more approachable. But there’s a flip side where people could be contacted for the wrong reasons if their name is public, in relation to these teams they work with.
- There’s some particular concern about lack of acknowledgement as it relates to the Security & IRT teams. People only know we handled an issue if we publicize it. So it might make it look like we don’t care about harassment or security if we don’t publicize that we handled certain things. Higher level of risk, a lot less reward. How do we find a balance?
- Security obviously has to be somewhat obscure, though the team does get recognition for individual work on the team, like when a release comes out. Every problem that’s fixed gets disclosed at that time, and generally the person who found the issue is mentioned. 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 Review team recently announced the people on the team, with their permission. Tricky team because they sometimes get negative feedback, so everyone gets a choice of whether to be mentioned.
- Discussed some of the other teams and whether/how their team members’ work is publicly acknowledged. Example: Design team creates elements for WordCamps, meetups – a lot of people don’t realize that logos and other design elements require people to create them. Folks need to know that work goes into it.
Types of recognition
- Recognition is multi-level, doesn’t just make someone feel good but also shows others that this work is being done, and gives others the opportunity to see a potential place they might be interested in getting involved.
- Different people want recognition in different ways. Which audience are we aiming recognition towards – peers? People outside of WP sphere? Self-recognition?
- Credits page in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. ties to release work, so a lot of people involved don’t get recognition. Particular problem with the 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. team where work is not tied to a particular release.
- Being asked to get involved with something specific can also have meaning. You’ve been asked to do something because people think you can bring value to something.
- Recap posts are a good time to post recognition. Difference in making work visible and being recognized. Event organizers often feel underappreciated but are approached for help so often.
- Different motives for being involved – i.e. are you sponsored or not? May be more inherent recognition if you’re sponsored. Reward system built in, i.e. your continued employment. People are known internally (within their company) for that part of the project but might not know folks outside of the company who are doing related work on the non-sponsored side.
- As a fully sponsored contributor, that desire for recognition is also still important to some.
Whose work do we want to show off/lift up/make more visible within the project? Let’s not forget those who do less visible work – are there tasks on teams that have a lower visibility, where the need for recognition is bigger? Also called the “glue” work.
Two types of target audiences to look at:
- Team-based, like: Support, Plugins, Meta, Security, IRT
- Task-based, like: administration, community, triage, mentorship work
- Lots of discussion around profile badges, with some people being more in favour and some less so. Discussed expanding the types of badges offered – for example, could have more “levels,” or even mention specific years in which someone was involved with a particular thing. Additional text could help make badges more meaningful and provide more nuance and context around someone’s current and historic involvement.
- There was some research done in the past around multi-level badges but the project has been on pause. If we picked it up, it could more adequately reflect people’s contributions. Levels might be easier to assign for some teams than others, because certain types of work are much less quantifiable. Some classification work can be automated, but some can’t, so would it really be the best use of our time?
- Some badges are more easily earned than others, so a badge doesn’t reflect a consistent amount of work. For example, a Polyglots badge doesn’t differentiate between amounts of work. In Core you can spend weeks writing a feature, and you get a single “prop” alongside others who make much smaller contributions. Committers have the option to give props to themselves, which can feel weird. Community folks have a similar issue – i.e. meetupMeetup All local/regional gatherings that are officially a part of the WordPress world but are not WordCamps are organized through https://www.meetup.com/. A meetup is typically a chance for local WordPress users to get together and share new ideas and seek help from one another. Searching for ‘WordPress’ on meetup.com will help you find options in your area. organizer vs. lead organizer of a 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. get the same badge, but they often reflect very different amounts of work.
- Teams work differently in terms of assigning badges, you might do a lot of work on one team but not have a badge for it. On some teams it’s automated (i.e. Photos), on others teams it’s manual (i.e. Support).
- Suggestion for current badge system to link each badge to the Make blog of the team it references, which could give lesser-known teams more exposure.
Sponsored vs. unsponsored/self-sponsored volunteers
- How do we ensure we have a pipeline of people for tasks that no one typically wants to sponsor, like admin tasks. How do you get past the thinking that admin work is not worthy of sponsorship?
- Sponsors expect a return on their investment in the form of recognition.
- Limited time to volunteer, how much are we limiting the base of contributions in general by making it seem you have to understand so much about the organization before you can jump in and volunteer. A lot of time is spent reading and catching up on what was missed or what has changed since the prior time they contributed. May not know how to spend their 2 available hours and thus don’t do it.
- Volunteers want to do what they enjoy doing, not necessarily what needs to be done in the project. No matter how much we need help with specific tasks, it’s not likely that we’re going to get people to volunteer to work on it if that’s not of interest to them. Different story for sponsored contributors.
Onboarding new volunteers
- With recent success of the mentoring program/cohort, is there a way to parlay success into some sort of rotation/sampling as we bring in a more focused mentoring program for new contributors, so those people can get a chance to experience multiple teams? Introduce them to some of these less seen teams, so they can potentially get involved somewhere they wouldn’t have encountered.
- New onboarding paths across all teams, all have links to “less than an hour” content for getting started.
- What are we doing to help people be able to do “drop in” contributions for smaller pieces of work?
- Formally identify target audiences.
- Investigate status of upgrades to badge system.
- Look into creating one dedicated questions/getting-started channel in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. to help overcome the overwhelm people can feel when trying to get started contributing.