Add label: OS-unsupported about core-workflow HOT 5 CLOSED

The downside [with adding to a project directly] is that they have to remember that projects exists and have to edit two separate fields

That's the main reason I'm proposing a label. All triagers know how to apply labels, so this doesn't change/complicate the process for them.
It does add a new queue/activity (assigning OSes in the project), but that can be handled by people who care about that.

Another reason is that labels are visible in overviews.

from core-workflow.

I see no opposition, so I've added the label, and set the project to auto-add labeled issues. Thanks for the thumbs ups everyone :)

(@mhsmith: I labeled an Android issue as OS-unsupported to test the auto-add. Hopefully we can label these as OS-android soon, so I won't go label the other ones.)

from core-workflow.

I think this is a very good idea.

from core-workflow.

If I understand correctly, we can set things up such that labeled issues are automatically added to a dedicated project, where they can be categorized/handled later.

There are at least 3 ways this can be automated:

• triagers add the issue to the project directly (can be done from the issue sidebar)
• triagers add a label, and this triggers the addition to the project (what you are suggesting)
• fully automated addition is configured on the project itself

The last option would be ideal because it requires no human intervention, but it would rely on queries like in:title <unsupported platform>. This will also allow to automatically add the issues on the right view of the project -- something that can't be otherwise automated easily. The queries might still miss some issues if the platform is not explicitly mentioned, or there might be some false positives, but these can be easily corrected (assuming it still gets most of them right).

This way, devs/triagers wouldn't need to care about GitHub projects, or “community-supported” platforms. Unless they want to :)

Note that nowadays triagers are able to add issues to project, and can do so from the right sidebar of the issue, just like they add labels. The downside is that they have to remember that projects exists and have to edit two separate fields (labels and projects) instead of just one (labels).

from core-workflow.

Devguide PR: python/devguide#1281

from core-workflow.