<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class="">I would like to see Swift Evolution adopt a couple of styles of fast track reviews. Chris Lattner</div><div class="">suggested I bring this up on-list for discussion to allow the community to offer feedback </div><div class="">on my idea.</div><div class=""><br class=""></div><div class=""><b class="">STYLE ONE: Minor language enhancements AKA "Low hanging fruit"</b></div><div class=""><br class=""></div><div class="">I would like the core team to be able to add minor language enhancements without going</div><div class="">through a formal proposal process, with its normal review overhead. I have now been</div><div class="">involved in several reviews that involved API changes that were otherwise unremarkable</div><div class="">and primarily motivated by modernizing and style:</div><div class=""><br class=""></div><div class="">* <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0040-attributecolons.md" class="">Replacing Equal Signs with Colons For Attribute Arguments</a></div><div class="">* <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0039-playgroundliterals.md" class="">Modernizing Playground Literals</a></div><div class="">* <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0034-disambiguating-line.md" class="">Disambiguating Line Control Statements from Debugging Identifiers</a></div><div class=""><br class=""></div><div class="">To this list, you could add:</div><div class=""><br class=""></div><div class="">* <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0053-remove-let-from-function-parameters.md" class="">Remove explicit use of let from Function Parameters</a></div><div class=""><br class=""></div><div class="">Each of these proposals could have proceeded with a simple "any objections" sanity check </div><div class="">discussion period rather than a more formal full review. As a another example</div><div class="">(<a href="https://github.com/apple/swift-evolution/pull/256" class="">now unnecessary</a>), consider the `dynamicType` keyword, which would have required</div><div class="">a formal proposal to be modernized into Swift's lowercase keyword standard.</div><div class=""><br class=""></div><div class="">The hallmarks of these changes are:</div><div class=""><br class=""></div><div class="">* They have limited impact</div><div class="">* They increase language consistency</div><div class="">* They are uncontroversial, offering simple, straightforward, and correct changes </div><div class=""> that have already passed review in spirit, if not in letter</div><div class="">* A preponderance of reviews are "+1" rather than in-depth discussions of why the proposal </div><div class=""> should or should not be adopted.</div><div class=""><br class=""></div><div class="">I would recommend retaining a change document requirement for these proposals.</div><div class="">This would be similar to a brief but formal proposal, that lays out the justification, </div><div class="">detail design, and any associated background info for the change. Doing so</div><div class="">would provide a historic record of the change and any notes from the team, and be </div><div class="">in a form that would support the extraction of key details for use in release notes.</div><div class=""><br class=""></div><div class="">I do not know whether these would need to be grouped and numbered with the normal</div><div class="">proposals or placed into their own numbering scheme.</div><div class=""><br class=""></div><div class=""><b class="">STYLE TWO: Fast tracking viability</b></div><div class=""><b class=""><br class=""></b></div><div class="">Once a draft has been discussed on-list and submitted as a pull request, I would like to</div><div class="">see a biweekly (or even once-a-month) <i class="">Pull Request Review</i> meeting from the core team</div><div class="">where a review groups looks over the current pull-request queue and scores them: </div><div class=""><i class="">recommend close</i>, <i class="">recommend promote</i>, <i class="">needs work</i>, <i class="">defer past 3.0</i>.</div><div class=""><br class=""></div><div class="">This approach:</div><div class=""><br class=""></div><div class="">* Would offer closure to proposal authors who are otherwise unsure of the viability</div><div class=""> of their proposals</div><div class=""><div class="">* Naturally happens after a significant on-list discussion/pre-review period has already </div><div class=""> taken place</div></div><div class="">* Would allow the team to weed out proposals with significant issues before entering</div><div class=""> formal review</div><div class="">* Would allow on-list reviews to give precedence to only those proposals that make sense</div><div class=""> both in the time context of Swift 3.0 and its overall design philosophy. </div><div class=""><br class=""></div><div class="">Swift is an opinionated language. This review style would introduce discernment and</div><div class="">feedback slightly earlier in the process without stifling on-list discussion.</div><div class=""><br class=""></div><div class=""><b class="">A few final thoughts</b></div><div class=""><b class=""><br class=""></b></div><div class="">It is a given that Swift 3 is going to be the last opportunity to make large, code-breaking</div><div class="">changes to the language. With that constraint, I'd like to see more time and effort go into</div><div class="">improving Swift's fundamentals. Any time, effort, and review that can be better spent</div><div class="">getting collections and indices right rather than worrying about colons and casing is,</div><div class="">in my opinion, worth a tradeoff in community control. </div><div class=""><br class=""></div><div class="">The natural tension between engagement and coherence requires a balance that serves</div><div class="">the entire Swift community. Open evolution processes are, by nature, chaotic. Maintaining</div><div class="">a coherent vision for something as complicated as Swift requires coordination and leadership. </div><div class="">That's why the ultimate responsibility for adopting changes lies with the Swift </div><div class="">core team, which establishes the strategic direction of Swift. </div><div class=""><br class=""></div><div class="">I hope by adopting these fast-track review styles that the Swift open source community </div><div class="">can better focus on the big updates while making sure that the small details are attended to</div><div class="">carefully and thoughtfully without overwhelming the process.</div><div class=""><br class=""></div><div class="">-- E</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>