-
Notifications
You must be signed in to change notification settings - Fork 256
Add Windows Workgroup #1222
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
base: main
Are you sure you want to change the base?
Add Windows Workgroup #1222
Conversation
Added a charter for the Windows workgroup, along with a membership list and some links.
aaa4730 to
7bd0555
Compare
|
|
||
| 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: |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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:
- 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.
- 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).
- 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.
Added profiling and Windows-specific tooling.
Added a charter for the Windows workgroup, along with a membership list and some links.