<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br><br>Sent from my iPhone</div><div><br>On Apr 18, 2016, at 8:56 AM, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><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></blockquote><div><br></div><div>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. </div><br><blockquote type="cite"><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></blockquote><div><br></div>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. <div><br></div><div> - Doug</div></body></html>