[swift-evolution] [META] Fast Track Reviews

[Douglas Gregor]

> On Apr 18, 2016, at 7:39 PM, Douglas Gregor via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> 
> Sent from my iPhone
> 
> On Apr 18, 2016, at 8:56 AM, Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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>
>> * Modernizing Playground Literals <https://github.com/apple/swift-evolution/blob/master/proposals/0039-playgroundliterals.md>
>> * Disambiguating Line Control Statements from Debugging Identifiers <https://github.com/apple/swift-evolution/blob/master/proposals/0034-disambiguating-line.md>
>> 
>> 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>
>> 
>> 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>), 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. 

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160422/ee19c0af/attachment-0001.html>