Expanding Swift Evolution to other project areas

[hborla (Holly Borla)]

This discussion about the evolution process is carried over from

SE-454: adopt mimalloc for Windows toolchain

I also object to this going through the evolution process. It’s reasonable for changes to the compiler to go through broad review sometimes, e.g. new command-line arguments, coming up with a platform support policy, and of course changes that would affect the output. But from reading the proposal, this is none of those, this is just an implementation decision. If it’s that important to gather feedback on, then sure, it could get a forum-wide announcement. It could even have a designated review …

The @contributor-experience-workgroup is currently working on generalizing the Swift Evolution process to apply to more areas of project development. You can read about this effort here:

@anthonylatsis

As the Swift ecosystem continues to accrete more building blocks and diversify, there is a rising demand for a scalable, community-driven process to guide its evolution beyond the language — one capable of gracefully embracing ideas that cross project boundaries and catering to not only select core elements like the Swift compiler and standard libraries but also to arbitrary satellite projects, whether they are in the early stages or well-established. The current Swift evolution process offers limited wiggle room for meeting the needs of other projects, leading some to launch their own tailored variations. For instance, swift-foundation has implemented a similar, albeit separate, API integration process. The CEWG is making substantial progress in fleshing out a proposed approach to a flexible standard for Swift evolution and related processes, with the aim of presenting this work the by end of the year.

The idea is that other steering groups should facilitate their own Swift Evolution process for major changes in the technical areas they oversee, including defining a proposal template that makes sense for the kinds of changes they'll be reviewing. Of course, not every change needs to have a formal review process, and it's up to the steering group to decide which changes should be formally reviewed and which changes should not. The Platform Steering Group charter and the Language Steering Group charter covers which technical areas it has "evolution authority" over, and a broad description of which kinds of changes should go through the evolution process. Other forthcoming steering groups will have similar sections in their charters.

One of the topics that the Contributor Experience Workgroup has discussed is whether to use the same SE number system for evolution proposals in different areas. We currently use the same SE number system for SwiftPM proposals and for language proposals, and I believe the current proposal from the Contribex Workgroup (which they're working on writing up) is to use the same SE numbering system for all proposals, and implement a tagging system in the proposal header and on the Swift Evolution Dashboard to easily filter proposals in different areas of the project. If it's valuable to create different sub-categories under the Swift Evolution category for different kinds of reviews, e.g. for notification purposes, that's also something we can consider. I think ultimately the numbering scheme for the proposal documents matters less than how reviewers interact with the proposals through Swift.org and on the Swift forums.

[Jumhyn (Frederick Kellison-Linn)]

Agreed regarding the numbering system being mostly immaterial. The biggest thing I think I'd want is this item you mention:

@hborla

If it's valuable to create different sub-categories under the Swift Evolution category for different kinds of reviews, e.g. for notification purposes, that's also something we can consider.

[jrose (Jordan Rose)]

I appreciate having this broken out. To reiterate*, my primary objection in the case of SE-454 is that it is an implementation detail, not that there shouldn’t be evolution proposals for projects besides the main Swift language. In my opinion, implementation details do not need the “evolution” style of review because there are (to a first approximation) no compatibility concerns. If mimalloc is added to the compiler now and removed again in two months, or even two releases, the only effects for users of the compiler will be memory usage and compile time, two things we care about but do not attempt to make guarantees about.

* which is not to say hborla missed this or deliberately ignored it; indeed, it’s in the quote! I only want it to be explicitly visible in the new thread.

[hborla (Holly Borla)]

Personally, I think there are cases where it's valuable to have a review process for major implementation-level changes, especially if there are alternatives to be considered and significant implications to the developer experience of the different alternatives (e.g. compile time performance, source compatibility, etc). There have been several instances of major compiler changes put up in PRs, and all of the information you'd have in a written proposal (e.g. motivation, alternatives, tradeoffs, etc) would have been extremely valuable to discuss in addition to the code change of the chosen approach, and that kind of discussion can be difficult to have on a GitHub PR. For example, replacing the implementation mechanism for generic signature type checking and minimization (the Generic Signature Builder -> Requirement Machine), didn't have a formal evolution review, but it did have source compatibility impact, and these tradeoffs were written up and discussed on the forums, just not in a place that's easily discoverable later.

This isn't to say that SE-0454 is definitely one of those cases. I think the Platform Steering Group is still figuring out which kinds of changes warrant a formal review process.

[Finagolfin]

I think @jrose's unspoken objection is that the formal review process is seen as more heavy-handed, which isn't really needed for such compiler backend changes that don't affect Swift compatibility or architecture, so he suggests "it should not be jammed into a proposal format that doesn’t match the change being proposed."

If the goal is simply a "review process" "that's easily discoverable later," maybe you can simply create some kind of new RFC proposal format, similar to what seems to have been applied to the vision documents lately. These RFCs wouldn't require as much of a writeup for the proposal and would just be a call for comment, ie "let us know of your mimalloc experiences and if you have any feedback." As it is, this mimalloc proposal doesn't say much, so that's all you really can ask for from the community for this proposal anyway.

[xwu (Xiaodi Wu)]

@Finagolfin

If the goal is simply a "review process" "that's easily discoverable later," maybe you can simply create some kind of new RFC proposal format, similar to what seems to have been applied to the vision documents lately. These RFCs wouldn't require as much of a writeup for the proposal and would just be a call for comment, ie "let us know of your mimalloc experiences and if you have any feedback." As it is, this mimalloc proposal doesn't say much, so that's all you really can ask for from the community for this proposal anyway.

Evolution proposals do not all have to use the document format adopted by the language steering group. SwiftPM proposals, for example, have their own template. The platform steering group is free to do the same: I assume SE-0454 uses our template simply because it's the first proposal from that steering group and the template is one that exists.

[sspringer (Stefan Springer)]

As a side note about the templates, a point that I think is kind of missing in the proposals is about how documentation should change if a feature is implemented. Implementation is only part of what has to be done, is always should be documented in a good way, and this is can more than the mere API documentation, sometimes existing documentation might have to be restructered.

[xwu (Xiaodi Wu)]

We've talked about this before. Certainly I, for one, agree that considering how a feature can be taught and documented is an important part of evaluating it.

However, expanding proposal templates to require this sort of information is irreconcilable from the immediately preceding feedback that the template is already too difficult or "heavy-handed." Anyway, no need to derail the principal topic here.

[Diggory]

@hborla

the Contribex Workgroup

(Snark) Did someone from Lumon name this? (/snark)

[al45tair (Alastair Houghton)]

@jrose

my primary objection in the case of SE-454 is that it is an implementation detail

Donning my Chair of Platform Steering Group hat for the moment, the PSG is very explicitly interested in certain implementation details, namely those that have an impact on cross-platform support; the exact set of things we're responsible for is detailed in our charter. We actually agree that the full Swift Evolution process can be heavy-handed, which is one reason that for this particular proposal we have forgone the usual pitch thread and jumped straight into review.

We think it is useful to run a review for this particular change because it means that we will be shipping the mimalloc code as part of Swift on the Windows platform. Adding extra things that we actually ship without any kind of review seems wrong, even if they are an implementation detail. It also seems like a good idea to involve the community (for instance, someone other than @compnerd, who proposed the change, might know of some reason why we shouldn't use mimalloc), and replacing the memory allocator is definitely a platform issue (e.g. if someone proposed doing this for Darwin, IMHO we should reject it — on Darwin the advantages of using the system allocator outweigh any advantage you might conceivably get from a third-party allocator, and if the system allocator isn't fast enough then we should be able to pressure the right people to fix that).

A final reason for running this particular review is that we actually wanted to try running one and see how it went, and since @compnerd is a PSG member, it made sense to pick on his change for our first attempt. If we find we need to make changes to how we do it as a result, so much the better.

Note that we aren't interested in being the implementation detail police :-) There will be plenty of cases where we don't need or want to get involved.

To further assuage your fears on this front, I should add that in a previous employment I saw the impact of over-engineered process on productivity first-hand, and I'm very much against process for process' sake. (If I bump into you in person somewhere, I'll happily tell you all about it… I have quite a few entertaining horror stories about exactly how bad that can get.)

@xwu

I assume SE-0454 uses our template simply because it's the first proposal from that steering group and the template is one that exists.

Yes, that's correct. We just grabbed the existing template and went from there. We could certainly have our own version of the template if people think that will help.

@Finagolfin

If the goal is simply a "review process" "that's easily discoverable later," maybe you can simply create some kind of new RFC proposal format, similar to what seems to have been applied to the vision documents lately.

We did discuss having our own separate process, and that was rejected in favour of sharing the existing Swift Evolution process, though for PSG run proposals we're responsible for scheduling and reviews. One of the reasons for sharing Swift Evolution, incidentally, is that there will be proposals that touch on both language and platform issues, and having one mechanism for both avoids any wrangling about which evolution mechanism gets used for a given proposal. Another is that the community is already familiar with the process.

If anyone is unsure, after looking at our charter, whether a change is something PSG will care about, please feel free to reach out and ask.

[Finagolfin]

@xwu

However, expanding proposal templates to require this sort of information is irreconcilable from the immediately preceding feedback that the template is already too difficult or "heavy-handed."

That wasn't meant as a criticism of the LSG process, merely a description. In fact, one could argue that since Swift is now a major project shipping on Apple's 2+ billion devices, it's still too light! As such, maybe his documentation requirement would make sense for LSG.

Conversely, PSG deals with other platforms that currently have a speck of that footprint deploying Swift, so it would make sense to keep their process lighter, as Alastair says he'd like to keep it.

@al45tair

the PSG is very explicitly interested in certain implementation details, namely those that have an impact on cross-platform support

How would this mimalloc proposal impact that? Honestly, nobody expects the compiler allocator choice to be subject to steering group review.

@al45tair

We did discuss having our own separate process, and that was rejected in favour of sharing the existing Swift Evolution process, though for PSG run proposals we're responsible for scheduling and reviews.

Everything you say about running PSG proposals through the evolution git repo but keeping it lighter sounds good, but maybe that can be formalized into some RFC name and description for all steering groups, so people know which level of scrutiny to expect.

@al45tair

Another is that the community is already familiar with the process.

That's precisely the problem, hence the first question from Kyle is why this even needed to be run through Evolution.

I like that this matter is being run by the community- I don't think anybody is against getting feedback- we just got alarmed that Windows compiler changes might now be subject to too much scrutiny. Now that you've assuaged our concern, maybe you should write that in a public PSG Evolution doc for future authors and reviewers, so they know these PSG reviews will be lighter.

[al45tair (Alastair Houghton)]

@Finagolfin

How would this mimalloc proposal impact that? Honestly, nobody expects the compiler allocator choice to be subject to steering group review.

As I said above, at least partly we're doing this particular review as an experiment just to try out the process and see what works and what doesn't. I do think it's valuable to review it anyway, as I think replacing the allocator does pose some interesting questions (I actually just thought of one of my own that I haven't already asked, so I might post that in the review thread…)

@Finagolfin

Everything you say about running PSG proposals through the evolution git repo but keeping it lighter sounds good, but maybe that can be formalized into some RFC name and description for all steering groups, so people know which level of scrutiny to expect.

I think we intend to deal with things brought to us on a case-by-case basis. There might be things we're interested in that we agree don't need a review (maybe just a PR is sufficient); there might be things that need only a lightweight review; and there might be things that need the full process. The key here is that I don't want us to get in the way of making useful progress.