# Community support for a platform **URL:** \ **Category:** Core Workflow\ **Created:** [January 31, 2024, 9:13am UTC](https://discuss.python.org/t/community-support-for-a-platform/44621 "2024-01-31T09:13:55Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![encukou](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/encukou/32/2461_2.png) [@encukou](https://discuss.python.org/u/encukou)\ **Post date:** [January 31, 2024, 9:39am UTC](https://discuss.python.org/t/community-support-for-a-platform/44621/2 "2024-01-31T09:39:06Z")
Continuing the discussion from [Should we close issues for platforms not covered by PEP 11 or under active development?](https://discuss.python.org/t/should-we-close-issues-for-platforms-not-covered-by-pep-11-or-under-active-development/16437): How to handle issue triage for unsupported platforms? I propose: - Add the issue to the [Unsupported platforms project](https://github.com/orgs/python/projects/27/views/1) - Better: add an `OS-unsupported` label, which would add the issue to the project automatically. The _platform_ field would be unset (to be categorized within the project later). This would mean triagers don’t need to care about the GitHub project. I’ve opened [core-workflow#526](https://github.com/python/core-workflow/issues/526) to add the label. - Close it as _not planned_ --- _[View the full topic](https://discuss.python.org/t/community-support-for-a-platform/44621)._