Proposal: Eliminate the Review phase

I would like to propose the elimination of the Review phase of the evolution proposals. Instead I propose the Core team to discuss privately and announce the decision for each proposal.


The Review phase gives the false impression of a democratic procedure, while in practice it is deeply aristocratic. The “aristocrats” here being 20-30 vocal enthusiasts with very strong opinions about almost every aspect of the language.

It is often repeated that the Review process is not the same as voting, but in practice if a proposal gets e.g. 20 overwhelmingly positive reviews, it gives the impression that there is strong community support. Similarly if it gets 20 very negative reviews, there is a strong feeling that this goes against the community’s wishes. So even though in theory the review process is not binding, it turns out that it very much is in practice.

I also think that this aristocratic model is very unfair to the larger swift community. People who are mostly users of Swift and not developers of Swift tend to be biased towards solving their own pet problems, not the ones that affect the most people.

In sort, I believe it would be beneficial if the core team had a stronger influence in the direction of the language instead of mostly doing clerical work for a small minority of users.


How can you know that the review has such big power?
Maybe it‘s just there to keep that minority busy ;-)

You bring up an important point, which is that many developers outside of Swift Ev have expressed they feel they have no voice and great frustration. The problem there is then to figure out how to realistically provide outreach in a way that solicits their needs and cares in a measurable way that doesn’t place undue requirements on the language developers and the core team.

Just spitballing but maybe there could be a way for proposals to generate a survey or questionnaire, making it simpler to estimate “community support”. Since the proposal process now must include a higher bar of commitment, namely a preliminary implementation, why can’t it include a precis that describes the change, the reason for the change, the costs of the change, and then asks for responses along the standard lines (level of support, fits with the language, is appropriate, freeform comment, etc).

This kind of thing could be evangelized at WWDC, deployed on, and announced through a very low traffic send-only email list. There is overhead but I don’t think the overhead would be extreme and it would counter a lot of the feeling that it is burdensome to participate in SE, that SE is elitist, and that a developer’s primary concern and responsibility is their paid work. It would also bring in a lot of voices who use Swift on a daily basis for projects at all scales in many contexts, including industry, private, and educational.


Hi Nick,

I understand (and feel!) your frustration. That said, the review phase is an important part of our process. It is intended to draw out position points from people that represent various sides of any ongoing debates. The Swift Core Team carefully looks at these and the positions help provide balance and perspective to the members of the core team (who themselves may not represent all points well).

I agree with you that sometimes it feels like there are a few outspoken people that steer things too strongly, but it is also true that it is not a strict democracy. The goal of the core team is to do the right thing for the long term direction of the language, not merely to tally the +1’s and -1’s.

That said, while dropping the review phase entirely doesn’t seem like an improvement, our process definitely isn’t perfect. If there are other ideas for how to make the review phase more productive, maybe that would help. For example, we could discourage discussions during the review phase, and try to stick to position statements?



Sometimes discussions are important to really understand the impact of the proposal, though. I’ve been guilty of steering some reviews a bit off-topic trying to understand their impact. Even with the best intentions, it’s sometimes hard to avoid.

Also, I don’t get the impression that the core team merely does clerical work - sometimes they propose really different solutions to the original proposal, like the A & B existential syntax ([Returned for Revision] SE-0095: Replace protocol<P1, P2> syntax with Any<P1, P2>) or the \MyType.someProperty key-path syntax ([Returned for revision] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift).

That’s maybe an argument for earlier involvement…