Recognising contributors work: discussion notes and potential opportunities

This post is a summary of a Slack discussion about how contributors are being recognized in the project, in general. While it’s important for the program team to consider many topics, directly addressing this one is out of scope for the team. This came up in a conversation between contributors who primarily contribute to the docs and coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. teams. As a result, the docs team will explore how to better recognize its contributors. Because this topic is relevant for every team throughout the project, it’s being summarized here for visibility.

Thank you to everyone who joined in that discussion. Here is a summary of the ideas and resources shared and a look at how things can move forward, with a few opportunities.

Notes

During this discussion a number of challenges to contributors and teams which everyone agreed on were identified, these ranged from:

  • Identifying what is a valued contribution.
  • Some teams work on standardized release cycles and others do not.
  • There are multiple types of contributions.
  • It’s not always easy to catch a contribution when it happens
  • Finding paths in contribution: how can someone know where and when they are going to follow a particular path within a team?

There are also implementation issues:

  • The credits page itself is only visible when a user clicks the ‘upgrade’ button on auto updates.
  • The difference between props vs team recognition.
  • Badges not being the entire solution.

There is also a lot of prior art:

Out of scope for the program team

A point to be clear about is the paths on each team are up to the teams themselves, as is managing their contributions. One thing the core program might do is look at where patterns of this exist and suggest things to work on.

It’s worth also noting a few other five-for-the-future discussions spiralled out of this one root discussion. Whilst not an issue to discuss, it’s worth focusing on distinct ways forward and not veering into other teams, or owned areas. There is already a 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/. space for this discussion and to not duplicate this work it is important to continue that there in #five-for-the-future.  The program team has a focus and keeping to that is important.

Opportunities

How does the team move forward with all this conversation and start some potential work? Out of the discussion there are some things that could be done and on purpose these are reduced to the easier things to focus on and build up.

  • Document all the ways contribution is recognized: this way each can be surfaced, and any team can know what could pick from to suit their purpose. 
  • Explore iterations to the noteworthy contributors section and credits. If time, doing this for 6.9 would be ideal.
  • Look at what other projects do and consider what could bring in. This is a longer term idea but looking outside is great for us to learn from and GitHub Community Discussions area has an interesting recognition system which was raised in discussion.

These are just to start with, but as it’s good to get started on things, finding distinct tasks is a good next step in such a long discussion, along with documenting and bringing to this make site.

Feedback is welcome on these opportunities as they have been proposed as next steps.

Props @desrosj, @jorbin, @estelaris for reviewing and contributing to this post.

#contribution