[swift-evolution] Proposal revision mechanics + schedule

[Chris Lattner]

<changing subject line>

On Jul 21, 2017, at 8:12 AM, Nevin Brackett-Rozinsky via swift-evolution <swift-evolution at swift.org> wrote:
> That said, I think it is highly important that we have clarity regarding what *is* the proper time, method, and process for raising issues with and suggesting modifications to approved proposals. If there is one thing we have learned recently it is that sometimes a proposed change sounds good and gets approved (110, 25, etc.) which subsequently turns out to have unintended detrimental consequences.
> 
> We are not infallible, and there will certainly be times in the future when we think a change is good in theory, but then after experiencing it in practice we recognize it has problems. When that happens—and happen it will—we need to be able to correct our course. And it is far better to fix such things before they are released to the wider world.

This is a great thing to discuss, and I don’t think that there is an iron-clad answer.  Keeping swift-evolution effective is a complex problem, because it is highly multi-dimentional space to optimize in.  We want to engage the community, encourage people to participate, allow people to push Swift in new directions (when that makes sense) and keep discussions productive and humane.  All of this serves a meta goal of harnessing the folks who participate on swift-evolution to make Swift the best language possible.

The constraints are obvious: on most non-trivial topics, there will be some disagreement, so not everyone can be happy.  There is only so much engineering time to build cool new things, so it has to be prioritized and divvied up somehow.  As you say, it is impossible to make perfect decisions up front, so revisions and iteration are inevitable.  Constraints like source and (looming) ABI stability restrict the kinds of changes that can be made.  This is made all the more complicated by the fact that a lot of the tradeoffs made are necessarily judgement calls (and occasionally quite subjective), and decisions must be made with imperfect information (e.g. how long it will take to develop a feature).  I think it is truly fantastic how engaged and productive swift-evolution is, particularly considering these challenges.

I don’t know how Swift 5 will go, but I would guess that it will be similar to the Swift 4 cycle, but will include changes made by learning from it.  If so, it means that Ted will define the overarching themes for the release, to help prioritize effort.  This is because currently Apple is paying for the majority of the engineering and they have a completely rationale right to determine how they spend that engineering time.  In addition to the major themes, there will be other areas of focus as well (some of which won’t impact swift-evolution, like improvements to build times, performance, and stability).

Development will continue for some period of time, building out new things and a “feature complete” point will be reached.  At this point, major changes will be restricted in an effort to stabilize and reduce risk for the release.  This doesn’t mean that “no changes” will be made, but as the release grinds inexorably towards its final GM build the scope of changes will be restricted more and more.  This is an interesting challenge given that “Beta 1” is usually the first release that goes out to the really broad Swift community, so it is the release that generates the most insight on where the changes have hit their mark or where they have missed.  It is incredibly important to enable a feedback loop between folks using the early Swift toolchain builds and the betas so that we can refine and improve things to be the best possible.

Given that we’re very very late in the Swift 4 cycle, this is why Ben is guiding feedback in a certain narrow way (and why Xiaodi is helping to reinforce that guidance).  As he says, there are certain changes that just *can’t* be made rationally at this late stage, because big or risky changes require an iteration and feedback cycle, and there isn’t time for it.

Going forward, we’ll all try to communicate what sorts of changes are appropriate at a given time.  That said, we can’t make a perfect prediction and guarantee an absolute schedule.  I know this can be frustrating, but it is simply the nature of having to make decisions without perfect information.

-Chris