Skip to content

Conversation

@al45tair
Copy link
Contributor

@al45tair al45tair commented Nov 6, 2025

Added a charter for the Windows workgroup, along with a membership list and some links.

Added a charter for the Windows workgroup, along with a membership
list and some links.
@al45tair al45tair force-pushed the add-windows-workgroup branch from aaa4730 to 7bd0555 Compare November 6, 2025 11:41
@al45tair al45tair marked this pull request as ready for review November 11, 2025 16:37
@al45tair al45tair requested a review from a team as a code owner November 11, 2025 16:37

Where the workgroup is uncertain of or unable to agree on the way forward, members may raise issues to the relevant Steering Group(s) for consideration. Significant decisions should be made following the usual Swift Evolution process to allow for community participation and Steering Group oversight.

The core members of the Windows workgroup are:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that we should be following the C++ WG model, and not have explicit membership lists or the distinction of "core" vs "non-core" members.

Copy link
Contributor Author

@al45tair al45tair Dec 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We discussed this in the Platform Steering Group meeting. The alternatives are:

  1. No list of members. Windows Working Group is contactable via a forums alias. Forums aliases are transparent though (see e.g. the C++ interoperability group), so you can see who the members are.
  2. List of "core" members (people whose full time job involves working on Windows; people can be added to or removed from the core member list by request).
  3. List of all members. Implies we update the Working Group page all the time, or we restrict membership which makes no sense for a Working Group.

We definitely don't want to do (3). I'd suggested (2) partly because I didn't realise the aliases had public member lists, but partly also because I thought it would be useful as a way for people to see that there was an increasing effort being put into support for Swift and its ecosystem on Windows (I'm not sure (1) quite gets us that, but it is at least more transparent than I had originally realised).

Personally, I still like (2). I know @compnerd prefers (1). Happy to leave the final decision up to Core Team.

@shahmishal shahmishal marked this pull request as draft December 1, 2025 23:26
Added profiling and Windows-specific tooling.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants