- last one to call in takes notes ;). Johannes was late, taking notes today
Should backend packages for API packages go through SSWG?
- 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.
Code of Conduct
- 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: email@example.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
Roadmap for mature projects like SwiftNIO
- 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
Governance model for NIO
- 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 had a core team, who should be represented
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
Next phase for the SSWG
- [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
command line parsing
- considering if the SSWG should encourage a cmdline parsing library
- there seems to be a need
- Vapor has one, they're happy with the core
- statd client is moved to github.com/apple/swift-statsd-client