September 19, 2019

johannesweiss · October 3, 2019, 4:34pm

house keeping

For example, should swift-log implementations go through the SSWG or not?
Tomer: Projects stand on their own. So if people want to be able to rely on the quality/stability etc of SSWG packages then it makes sense for them to go through too
Others agree. So we should encourage people to go through the incubation process.

Tomer talked to CNCF folks what they do for smaller projects. Things are clear for bigger entities like Vapor, IBM, or Apple. But what about smaller projects? CNCF has a catch-all email for code of conduct issues in all packages. The CNCF folks also get some form of training on how to deal with these issues.
We should also do a catch all.
Tanner: Should we make an amendment to use catch-all for projects that don't have a dedicated CoC email address?
Yes, good idea
Current address is: swift-server-conduct@group.apple.com , currently only Apple employees.
Tanner: maybe a @swift.org email address?
For now let's add Allen & Ted for now and in the future, let's sort out emails for @swift-server.group

folks like Tom, Ben Cohen, Ted, and Johannes have been talking on how to get the community more involved in what's next and what's important for SwiftNIO to help us drive the directions and roadmap for SwiftNIO
Tom started to put together a governance document to be more inclusive in the process in deciding the future directions for NIO instead of just Apple deciding
We're interested in opinions. One idea would be the adoption of the evolution process but that might be too heavyweight
for SwiftNIO it's more about major changes. Examples are dropping supported Swift versions; major API/abstraction changes; major new protocols (eg. QUIC).
Vapor uses github issues but if something's a pretty big change then they usually ask the contributor to open a forums post to discuss the issue in an evolution-lite like process. Less structured than evolution though.
could also go full github but announce on the forums

another question is that Swift itself has a 'core team' which does the final decision. In smaller projects is often the group of the committers who do the decisions and not a separate core team. We are interested to know the thoughts if SwiftNIO should adopt the model with a core team or not.
Tanner: think there should be a core team as that's well understood and also what Swift/Vapor are doing
clarification: committer == has repo write access
question is really: should we be closer to Swift's model or should we be closer to more regular smaller OSS projects
Vapor has two tiers apart from the anyone who opens PRs: core team; contributors (can do pretty much everything but merge PRs to master)
goal for SwiftNIO is to get everything explicitly written down

if we were to create a core team, should "users" also be represented in that team?
Vapor's core team is only people who works on Vapor full time or at least serious part time
[ACTION] Tomer: send around a proposal document for a governance model

[ACTION] Tomer: Organise an out-of-band meeting regarding the next phase of the workgroup
a good point in time to announce the goals/... for the next phase would be the ServerSide.swift conference
[ACTION] Tanner: Send around the blog post draft to everybody

Johannes: update on the last PRs, mostly regarding event loop preferences
Tanner/Johannes: discussion around channel pool locality, performance regarding event loop preference

tkrajacic · October 3, 2019, 5:01pm

johannesweiss · October 5, 2019, 9:58am

Thank you!! Fixed