Memikirkan Kembali Pengakuan Kontributor di Tim Dokumentasi

At the Documentation Team meeting on October 21, 2025, we started an important conversation: How do we properly recognize contributions and how do we create clear paths for people who want to contribute once, versus those who want to grow into long-term team members?

This discussion surfaced everything from value perception, to badges, to long-term career benefits. Below is a summary of the key questions we’re exploring as we refine a contributor journey that is fair, motivating and future-proof.

What counts as a “valued” documentation contribution?

Not all contributions have the same impact — and contributors know it. We acknowledged that fixing a small typo is not the same as drafting or updating full documentation for a new feature. But where do we draw that line clearly?

We need to define:

• What is considered a regular (ongoing/essential) contribution?
• What is considered noteworthy — something worthy of highlight in a release announcement?
• How do we document these contributions for transparency?

Recognition systems: Props, badges, highlights… or something new?

We asked ourselves:

• Badges are still meaningful, when should we provide the docs contributor badge vs the docs team badge?
• What’s the difference between props on a release and props in the Slack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. #props channel?
• Should we distinguish clearly between one-time contributors and active team members?
• Should recognition appear more frequently, e.g. monthly or even at every weekly meeting?
• Should we publish recognitions in the Make/Docs weekly updates or Week in Docs posts — similar to other teams?

Several agreed that contributor recognition should happen more often. A one-time contributor should get the contributor badge as small contributions still matter.

Defining growth paths — beyond “show up and help”

We want to answer two different needs:

1. I want to contribute once / occasionally — how do I-do that and get recognized confidently?
2. I want to grow into a team member or specialist — what path can I follow? What are the levels?

We could create progressive roles — for example, team members take on responsibilities like:

• Maintaining a documentation project or focus on the handbook
• Being the person responsible for HelpHub or DevHub areas
• Assisting with leadership tasks (triage, reviews, release prep)
• Being considered for Team Rep A Team Rep is a person who represents the Make WordPress team to the rest of the project, make sure issues are raised and addressed as needed, and coordinates cross-team efforts. based on initiative over time

We want to do this more intentionally.

There is also interest in offering a structured program — e.g. a 6-month pathway where contributors could earn a recognized professional title, such as Technical Writer (Docs Team) — something they could confidently add to their CV or LinkedIn.

When and where should recognition happen?

We explored timing:

• Should recognition align with release cycles?
• Or would monthly or quarterly acknowledgment be more meaningful and visible?
• Could recognitions be part of each weekly meeting agenda/notes?
• Example: “Contributor Recognitions — username username”
• Should these recognitions also be included in Make blog updates?

We also noted that the WordPress Credits page is only visible if a user manually clicks “upgrade,” not during auto-updates which means that WP release recognition is currently invisible to most users.

Are contributors feeling valued beyond public recognition?

Badges and props are great — but contributors also contribute in invisible ways:

• Running meetings
• Writing meeting notes
• Triaging and reviewing GitHub 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/ issues
• Reviewing and updating articles
• Leading Contributor 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/. tables

We asked: Are these roles recognized equally? Should they be?

And finally — does attending a Contributor Day actually advance someone’s contributor journey?
Answer: Yes — participation at a Docs table currently qualifies contributors to receive the Docs Contributor Badge, provided table leads submit their names.

What’s next?

This is the beginning of a larger effort — our goal is to build a clear, transparent contribution pathway that supports:

• Casual contributors
• Returning contributors
• Aspiring team members
• Professionals seeking career credibility
• Future leaders

We want contributors to feel not just recognized — but valued, supported, and growing.

This conversation will continue, and we invite the wider Docs community to help co-create the next iteration of what meaningful contribution looks like.

With these points in mind, we have one clear action item which is to create a method, perhaps using gamification, to quantify the number of contributions. @milana_cap will review what options are available.

Props to @milana_cap for reviewing this post.

#contributor-recognition, #handbooks, #new-ideas