Skip to content

Add label: OS-unsupported #526

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
encukou opened this issue Jan 31, 2024 · 5 comments
Closed

Add label: OS-unsupported #526

encukou opened this issue Jan 31, 2024 · 5 comments
Assignees
Labels
labels Issues related to GitHub label changes

Comments

@encukou
Copy link
Member

encukou commented Jan 31, 2024

Request for label changes on python/cpython

I'm proposing a OS-unsupported label, to be used for platforms not listed in PEP-11.
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. This way, devs/triagers wouldn't need to care about GitHub projects, or “community-supported” platforms. Unless they want to :)

Broader discussion: https://discuss.python.org/t/44621/2

@encukou encukou added the labels Issues related to GitHub label changes label Jan 31, 2024
@erlend-aasland
Copy link

I think this is a very good idea.

@ezio-melotti
Copy link
Member

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).

@encukou
Copy link
Member Author

encukou commented Feb 1, 2024

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.

@encukou
Copy link
Member Author

encukou commented Feb 28, 2024

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.)

@encukou encukou closed this as completed Feb 28, 2024
@encukou
Copy link
Member Author

encukou commented Feb 28, 2024

Devguide PR: python/devguide#1281

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
labels Issues related to GitHub label changes
Projects
None yet
Development

No branches or pull requests

3 participants