Communicate with community how we prioritize issues

[avillela]

Per request from @austinlparker in this Slack conversation -- Target end of June for completion

[reese-lee]

Per Austin's original Slack message:

hi folks - random project/happenable thing. i would like for us to better communicate to the community how they can prioritize issues, and also issue some guidance for maintainers on it. my gut/initial feeling is that we should communicate to users that using the +1/thumbs up reaction in github is the preferred method to vote on a feature/issue. what would be great to validate is the following:
that we’re communicating to end users that issue voting through reactions exists and that we care about it
that maintainers/triagers are using the +1/thumbs up reaction to prioritize backlogged work
that we can normalize this practice across repos/SIGs
if someone could take this as a project that’d be swell

[reese-lee]

ACTION ITEMS:

• Communicate at Maintainer meeting and confirm participation --> June 10
• Communicate in our SIG repo, link to the item below -- include that you can sort issues by number of votes
• Communicate on our End user resources site -- create a new page
• See if we can update somewhere with an announcement in the repo? Like at the top under "Want to contribute...?"

[danielgblanco]

I think that before we communicate it to maintainers in the maintainers meeting, to get some feedback, we should put together a small proposal of how we'd see it working for them and end-users. Here's a few things I've been thinking about

We would like end-users and contributors to use "thumbs up" reactions to express interest in issues

We want to give a clear message to users and to contributors that, if there's something in particular that they want to see addressed, or implemented, they should interact with our maintainers and use "thumbs up" reactions in issues to do so. This will be publicised in our website, and ideally also in all repos, although looking at the GitHub docs this may only be possible as a big banner in every page... Not ideal. If there was a way to keep that closer to issues (maybe in default issue templates so it shows in the issues themselves) it'd be great.

We would like maintainers to use reactions in their planning process

We would like maintainers to use reactions to prioritise issues. It's up to individual SIGs how they use this information, and we don't expect them to solely base their prioritisation on reactions, as there are other matters that will take precedence. However, a pointer on how to sort issues this way, documented in the community repo could help as a reference (see this filter for instance). We'll also need to socialise this advice with individual SIGs, and GC liaisons can help here.

We would like SIGs to communicate prioritisation back to the community and end-users

As explained in the previous point, users will upvote issues but it'll be normal for other issues with fewer votes to take priority. It is important that SIGs can communicate their priorities back to users, so if they see their issue with the most upvotes is not progressing, they can understand what's taking precedence in the backlog. This will avoid frustration for end-users but also give them a way to see progress towards the issues they care most about.

One way to do this would be via Project Boards, where maintainers can display a prioritised backlog. Of course not all issues should be on the board, but rather what's currently the focus of a SIG. At the moment, the GC is not requesting SIGs to have such boards, only for individual projects, and SIGs can communicate their priorities as they see fit. If this is the agreed behaviour, and Project Boards are not mandated (or strongly encouraged), we'd need SIGs to communicate priorities in some way that's public and discoverable (i.e. not Google Docs or tracking issues that other users may not know about).

[avillela]

@danielgblanco I really like this. Let's table this for dicussion at our next SIG meeting (I've added it to the agenda).

[danielgblanco]

I've put together some thoughts on https://docs.google.com/document/d/1i87ahvEZws-TdRHGYpK0iTVrPFJZWrwfF7ucemOoQmI. Would appreciate any comments before socialising this and getting buy-in from maintainers (if we want to do it).

[reese-lee]

@danielgblanco I think it's fairly thorough, thank you! I left a comment. I imagine there'll be more questions to ponder once it's presented to SIG maintainers.

[danielgblanco]

The document above received a few comments and I think we can move forward with:

1. Changes in contributor guide to clearly state the expectations from maintainers (i.e. not expecting them to automatically prioritise the highest voted)
2. Changes to website community page.
3. Changes to issue templates across the project to add the sub-heading after those two have been completed (I will split that into a different issue under this repo to track it)