[META] Fast Track Reviews

Evolution Discussion
1

I would like to see Swift Evolution adopt a couple of styles of fast track reviews. Chris Lattner
suggested I bring this up on-list for discussion to allow the community to offer feedback
on my idea.

STYLE ONE: Minor language enhancements AKA "Low hanging fruit"

I would like the core team to be able to add minor language enhancements without going
through a formal proposal process, with its normal review overhead. I have now been
involved in several reviews that involved API changes that were otherwise unremarkable
and primarily motivated by modernizing and style:

* Replacing Equal Signs with Colons For Attribute Arguments <https://github.com/apple/swift-evolution/blob/master/proposals/0040-attributecolons.md&gt;
* Modernizing Playground Literals <https://github.com/apple/swift-evolution/blob/master/proposals/0039-playgroundliterals.md&gt;
* Disambiguating Line Control Statements from Debugging Identifiers <https://github.com/apple/swift-evolution/blob/master/proposals/0034-disambiguating-line.md&gt;

To this list, you could add:

* Remove explicit use of let from Function Parameters <https://github.com/apple/swift-evolution/blob/master/proposals/0053-remove-let-from-function-parameters.md&gt;

Each of these proposals could have proceeded with a simple "any objections" sanity check
discussion period rather than a more formal full review. As a another example
(now unnecessary <https://github.com/apple/swift-evolution/pull/256&gt;\), consider the `dynamicType` keyword, which would have required
a formal proposal to be modernized into Swift's lowercase keyword standard.

The hallmarks of these changes are:

* They have limited impact
* They increase language consistency
* They are uncontroversial, offering simple, straightforward, and correct changes
   that have already passed review in spirit, if not in letter
* A preponderance of reviews are "+1" rather than in-depth discussions of why the proposal
  should or should not be adopted.

I would recommend retaining a change document requirement for these proposals.
This would be similar to a brief but formal proposal, that lays out the justification,
detail design, and any associated background info for the change. Doing so
would provide a historic record of the change and any notes from the team, and be
in a form that would support the extraction of key details for use in release notes.

I do not know whether these would need to be grouped and numbered with the normal
proposals or placed into their own numbering scheme.

STYLE TWO: Fast tracking viability

Once a draft has been discussed on-list and submitted as a pull request, I would like to
see a biweekly (or even once-a-month) Pull Request Review meeting from the core team
where a review groups looks over the current pull-request queue and scores them:
recommend close, recommend promote, needs work, defer past 3.0.

This approach:

* Would offer closure to proposal authors who are otherwise unsure of the viability
  of their proposals
* Naturally happens after a significant on-list discussion/pre-review period has already
   taken place
* Would allow the team to weed out proposals with significant issues before entering
   formal review
* Would allow on-list reviews to give precedence to only those proposals that make sense
   both in the time context of Swift 3.0 and its overall design philosophy.

Swift is an opinionated language. This review style would introduce discernment and
feedback slightly earlier in the process without stifling on-list discussion.

A few final thoughts

It is a given that Swift 3 is going to be the last opportunity to make large, code-breaking
changes to the language. With that constraint, I'd like to see more time and effort go into
improving Swift's fundamentals. Any time, effort, and review that can be better spent
getting collections and indices right rather than worrying about colons and casing is,
in my opinion, worth a tradeoff in community control.

The natural tension between engagement and coherence requires a balance that serves
the entire Swift community. Open evolution processes are, by nature, chaotic. Maintaining
a coherent vision for something as complicated as Swift requires coordination and leadership.
That's why the ultimate responsibility for adopting changes lies with the Swift
core team, which establishes the strategic direction of Swift.

I hope by adopting these fast-track review styles that the Swift open source community
can better focus on the big updates while making sure that the small details are attended to
carefully and thoughtfully without overwhelming the process.

-- E

2

+2. I think both of these processes, if practical for the team, would
benefit the community. There are lots of PRs
<https://github.com/apple/swift-evolution/pulls&gt; that have sat open for
months with no response.

Another idea: track evolution proposals on the bugs.swift.org JIRA
installation, by creating a new project
<https://bugs.swift.org/secure/BrowseProjects.jspa?selectedCategory=all&selectedProjectType=all&gt;
for the SEs. The SE-nnnn number in the proposal text could match the JIRA
number. Then the team could use custom JIRA workflows
<https://confluence.atlassian.com/adminjiraserver070/working-with-workflows-749383109.html&gt;
and statuses
<https://confluence.atlassian.com/adminjiraserver070/defining-status-field-values-749382903.html&gt;
to track proposals more closely and make the internal process visible to
the community.

Jacob

···

On Mon, Apr 18, 2016 at 8:56 AM, Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote:

I would like to see Swift Evolution adopt a couple of styles of fast track
reviews. Chris Lattner
suggested I bring this up on-list for discussion to allow the community to
offer feedback
on my idea.

*STYLE ONE: Minor language enhancements AKA "Low hanging fruit"*

I would like the core team to be able to add minor language enhancements
without going
through a formal proposal process, with its normal review overhead. I have
now been
involved in several reviews that involved API changes that were otherwise
unremarkable
and primarily motivated by modernizing and style:

* Replacing Equal Signs with Colons For Attribute Arguments
<https://github.com/apple/swift-evolution/blob/master/proposals/0040-attributecolons.md&gt;
* Modernizing Playground Literals
<https://github.com/apple/swift-evolution/blob/master/proposals/0039-playgroundliterals.md&gt;
* Disambiguating Line Control Statements from Debugging Identifiers
<https://github.com/apple/swift-evolution/blob/master/proposals/0034-disambiguating-line.md&gt;

To this list, you could add:

* Remove explicit use of let from Function Parameters
<https://github.com/apple/swift-evolution/blob/master/proposals/0053-remove-let-from-function-parameters.md&gt;

Each of these proposals could have proceeded with a simple "any
objections" sanity check
discussion period rather than a more formal full review. As a another
example
(now unnecessary <https://github.com/apple/swift-evolution/pull/256&gt;\),
consider the `dynamicType` keyword, which would have required
a formal proposal to be modernized into Swift's lowercase keyword standard.

The hallmarks of these changes are:

* They have limited impact
* They increase language consistency
* They are uncontroversial, offering simple, straightforward, and correct
changes
   that have already passed review in spirit, if not in letter
* A preponderance of reviews are "+1" rather than in-depth discussions of
why the proposal
  should or should not be adopted.

I would recommend retaining a change document requirement for these
proposals.
This would be similar to a brief but formal proposal, that lays out the
justification,
detail design, and any associated background info for the change. Doing so
would provide a historic record of the change and any notes from the team,
and be
in a form that would support the extraction of key details for use in
release notes.

I do not know whether these would need to be grouped and numbered with the
normal
proposals or placed into their own numbering scheme.

*STYLE TWO: Fast tracking viability*

Once a draft has been discussed on-list and submitted as a pull request, I
would like to
see a biweekly (or even once-a-month) *Pull Request Review* meeting from
the core team
where a review groups looks over the current pull-request queue and scores
them:
*recommend close*, *recommend promote*, *needs work*, *defer past 3.0*.

This approach:

* Would offer closure to proposal authors who are otherwise unsure of the
viability
  of their proposals
* Naturally happens after a significant on-list discussion/pre-review
period has already
   taken place
* Would allow the team to weed out proposals with significant issues
before entering
   formal review
* Would allow on-list reviews to give precedence to only those proposals
that make sense
   both in the time context of Swift 3.0 and its overall design
philosophy.

Swift is an opinionated language. This review style would introduce
discernment and
feedback slightly earlier in the process without stifling on-list
discussion.

*A few final thoughts*

It is a given that Swift 3 is going to be the last opportunity to make
large, code-breaking
changes to the language. With that constraint, I'd like to see more time
and effort go into
improving Swift's fundamentals. Any time, effort, and review that can be
better spent
getting collections and indices right rather than worrying about colons
and casing is,
in my opinion, worth a tradeoff in community control.

The natural tension between engagement and coherence requires a balance
that serves
the entire Swift community. Open evolution processes are, by nature,
chaotic. Maintaining
a coherent vision for something as complicated as Swift requires
coordination and leadership.
That's why the ultimate responsibility for adopting changes lies with the
Swift
core team, which establishes the strategic direction of Swift.

I hope by adopting these fast-track review styles that the Swift open
source community
can better focus on the big updates while making sure that the small
details are attended to
carefully and thoughtfully without overwhelming the process.

-- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

3

STYLE ONE: Minor language enhancements AKA "Low hanging fruit"

I would like the core team to be able to add minor language enhancements without going
through a formal proposal process, with its normal review overhead. I have now been
involved in several reviews that involved API changes that were otherwise unremarkable
and primarily motivated by modernizing and style:

* Replacing Equal Signs with Colons For Attribute Arguments
* Modernizing Playground Literals
* Disambiguating Line Control Statements from Debugging Identifiers

To this list, you could add:

* Remove explicit use of let from Function Parameters

These examples are all very small changes, practically as easy to write as to propose comprehensively. I wonder if these sorts of things could simply be merged into master, preferably behind a feature flag if they break anything, and reviewed at the time of the next snapshot. This would allow people to actually play with the change and see how they feel about it. If people are happy with it, we remove the feature flags, finish up tests/diagnostics/documentation/deprecations, and move on. If not, modify or revert.

I think it's very important to have some kind of proposal for every change, particularly so we have a Motivations section, which is *not* something you can get from compiler diffs. I also think it's important that every change have some kind of review: it gets the idea in front of the eyes of non-compiler-writers, provides an opportunity for feedback, acts as a waiting period in case there's a better idea floating just out of reach, and legitimizes the change in the eyes of the community. (And I think all reviews, even abbreviated ones, should go out on -announce; I know a few people who can't follow swift-evolution but do read reviewed proposals to keep up with things.)

But that doesn't mean every change has to go through the same process. If the change is simple, its "proposal" can be a couple paragraphs, and its "review" can be during or after implementation, as long as it's considered non-final. We can do something lightweight for the small stuff, as long as everyone is afforded an opportunity to contribute.

(And having something already implemented may help keep bikeshedding under control. It's one thing to argue about the color before the bikeshed is painted; arguing afterward is quite another.)

A few final thoughts

It is a given that Swift 3 is going to be the last opportunity to make large, code-breaking
changes to the language. With that constraint, I'd like to see more time and effort go into
improving Swift's fundamentals. Any time, effort, and review that can be better spent
getting collections and indices right rather than worrying about colons and casing is,
in my opinion, worth a tradeoff in community control.

Yes and no. Colons and casing are only going to get harder to change. What I *do* think, though, is that we need to focus on getting what we have nailed down and polished up, rather than adding a bunch of new stuff. There are very few missing features which are so urgent that they can't wait* until 3.1 or 3.2 or even 4.0, but existing features' designs and names—particularly in standard library protocols—are almost frozen in the fall.

To that end, I'm wondering if we should branch swift-evolution in the same way we branch master. swift3-evolution would focus on redesigns, minor extensions, and the few new features urgent enough to be part of Swift 3; swift-evolution would orient towards drafting and refining proposals for larger features which probably won't make the cut. (We wouldn't be reviewing these yet, but we can get things prepped.) The people who are busy implementing things can then focus on swift3-evolution and only occasionally weigh in on swift-evolution. I think this would make the current status clear and take a load off the people who are swamped.

* The only missing feature I can think of which *is* that urgent is new sequence operations to soften the blow of the C-style for loop removal. We need *something* to fix-it those old loops into.

···

--
Brent Royal-Gordon
Architechies

4

I would like to see Swift Evolution adopt a couple of styles of fast track reviews. Chris Lattner
suggested I bring this up on-list for discussion to allow the community to offer feedback
on my idea.

STYLE ONE: Minor language enhancements AKA "Low hanging fruit"

I would like the core team to be able to add minor language enhancements without going
through a formal proposal process, with its normal review overhead. I have now been
involved in several reviews that involved API changes that were otherwise unremarkable
and primarily motivated by modernizing and style:

* Replacing Equal Signs with Colons For Attribute Arguments
* Modernizing Playground Literals
* Disambiguating Line Control Statements from Debugging Identifiers

To this list, you could add:

* Remove explicit use of let from Function Parameters

Each of these proposals could have proceeded with a simple "any objections" sanity check
discussion period rather than a more formal full review. As a another example
(now unnecessary), consider the `dynamicType` keyword, which would have required
a formal proposal to be modernized into Swift's lowercase keyword standard.

The hallmarks of these changes are:

* They have limited impact
* They increase language consistency
* They are uncontroversial, offering simple, straightforward, and correct changes
   that have already passed review in spirit, if not in letter
* A preponderance of reviews are "+1" rather than in-depth discussions of why the proposal
  should or should not be adopted.

I would recommend retaining a change document requirement for these proposals.
This would be similar to a brief but formal proposal, that lays out the justification,
detail design, and any associated background info for the change. Doing so
would provide a historic record of the change and any notes from the team, and be
in a form that would support the extraction of key details for use in release notes.

I do not know whether these would need to be grouped and numbered with the normal
proposals or placed into their own numbering scheme.

My main concerns are to have a proper paper trail documenting when and why we make a change. My preferred approach here would be to go through the normal process up to the pull request for the proposal... Then if it's obviously small and good, the core team could just go straight to accept, sending out an announcement.

STYLE TWO: Fast tracking viability

Once a draft has been discussed on-list and submitted as a pull request, I would like to
see a biweekly (or even once-a-month) Pull Request Review meeting from the core team
where a review groups looks over the current pull-request queue and scores them:
recommend close, recommend promote, needs work, defer past 3.0.

This approach:

* Would offer closure to proposal authors who are otherwise unsure of the viability
  of their proposals
* Naturally happens after a significant on-list discussion/pre-review period has already
   taken place
* Would allow the team to weed out proposals with significant issues before entering
   formal review
* Would allow on-list reviews to give precedence to only those proposals that make sense
   both in the time context of Swift 3.0 and its overall design philosophy.

Swift is an opinionated language. This review style would introduce discernment and
feedback slightly earlier in the process without stifling on-list discussion.

FWIW, we've been doing somethings similar to this already, looking at the outstanding PRs and accepting/deferring/sending them back. It's fairly time-consuming and the core team is stretched pretty thin, so I'm not sure what else we can do on this front. I suspect we can be a bit quicker to accept at this stage in the process to save us some overhead.

  - Doug

···

Sent from my iPhone

On Apr 18, 2016, at 8:56 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

5

It's all appreciated.

-- E

···

On Apr 18, 2016, at 8:39 PM, Douglas Gregor <dgregor@apple.com> wrote:

FWIW, we've been doing somethings similar to this already, looking at the outstanding PRs and accepting/deferring/sending them back. It's fairly time-consuming and the core team is stretched pretty thin, so I'm not sure what else we can do on this front. I suspect we can be a bit quicker to accept at this stage in the process to save us some overhead.

  - Doug

6

The core team did discuss this, and we agreed that there are small changes (particularly those that come from actually implementing the proposal) that could be treated as “bug fixes” to the proposal. When we accept such a pull request, we will send out an [Amendment] to swift-evolution [*].

We expect to use this sparingly. The removal of the vestigial “let” from function parameter lists is one case where we could have done this, the others are on the fence.

  - Doug

[*] I still owe one of these for a recent pull request we accepted to amend SE-0016.

···

On Apr 18, 2016, at 7:39 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

Sent from my iPhone

On Apr 18, 2016, at 8:56 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I would like to see Swift Evolution adopt a couple of styles of fast track reviews. Chris Lattner
suggested I bring this up on-list for discussion to allow the community to offer feedback
on my idea.

STYLE ONE: Minor language enhancements AKA "Low hanging fruit"

I would like the core team to be able to add minor language enhancements without going
through a formal proposal process, with its normal review overhead. I have now been
involved in several reviews that involved API changes that were otherwise unremarkable
and primarily motivated by modernizing and style:

* Replacing Equal Signs with Colons For Attribute Arguments <https://github.com/apple/swift-evolution/blob/master/proposals/0040-attributecolons.md&gt;
* Modernizing Playground Literals <https://github.com/apple/swift-evolution/blob/master/proposals/0039-playgroundliterals.md&gt;
* Disambiguating Line Control Statements from Debugging Identifiers <https://github.com/apple/swift-evolution/blob/master/proposals/0034-disambiguating-line.md&gt;

To this list, you could add:

* Remove explicit use of let from Function Parameters <https://github.com/apple/swift-evolution/blob/master/proposals/0053-remove-let-from-function-parameters.md&gt;

Each of these proposals could have proceeded with a simple "any objections" sanity check
discussion period rather than a more formal full review. As a another example
(now unnecessary <https://github.com/apple/swift-evolution/pull/256&gt;\), consider the `dynamicType` keyword, which would have required
a formal proposal to be modernized into Swift's lowercase keyword standard.

The hallmarks of these changes are:

* They have limited impact
* They increase language consistency
* They are uncontroversial, offering simple, straightforward, and correct changes
   that have already passed review in spirit, if not in letter
* A preponderance of reviews are "+1" rather than in-depth discussions of why the proposal
  should or should not be adopted.

I would recommend retaining a change document requirement for these proposals.
This would be similar to a brief but formal proposal, that lays out the justification,
detail design, and any associated background info for the change. Doing so
would provide a historic record of the change and any notes from the team, and be
in a form that would support the extraction of key details for use in release notes.

I do not know whether these would need to be grouped and numbered with the normal
proposals or placed into their own numbering scheme.

My main concerns are to have a proper paper trail documenting when and why we make a change. My preferred approach here would be to go through the normal process up to the pull request for the proposal... Then if it's obviously small and good, the core team could just go straight to accept, sending out an announcement.