<div dir="ltr">+2. I think both of these processes, if practical for the team, would benefit the community. There are <a href="https://github.com/apple/swift-evolution/pulls">lots of PRs</a> that have sat open for months with no response.<div><br></div><div>Another idea: track evolution proposals on the <a href="http://bugs.swift.org">bugs.swift.org</a> JIRA installation, by creating <a href="https://bugs.swift.org/secure/BrowseProjects.jspa?selectedCategory=all&selectedProjectType=all">a new project</a> for the SEs. The SE-nnnn number in the proposal text could match the JIRA number. Then the team could use custom JIRA <a href="https://confluence.atlassian.com/adminjiraserver070/working-with-workflows-749383109.html">workflows</a> and <a href="https://confluence.atlassian.com/adminjiraserver070/defining-status-field-values-749382903.html">statuses</a> to track proposals more closely and make the internal process visible to the community.</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div>Jacob<br></div></div></div></div>
<br><div class="gmail_quote">On Mon, Apr 18, 2016 at 8:56 AM, Erica Sadun via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br>I would like to see Swift Evolution adopt a couple of styles of fast track reviews. Chris Lattner</div><div>suggested I bring this up on-list for discussion to allow the community to offer feedback </div><div>on my idea.</div><div><br></div><div><b>STYLE ONE: Minor language enhancements AKA "Low hanging fruit"</b></div><div><br></div><div>I would like the core team to be able to add minor language enhancements without going</div><div>through a formal proposal process, with its normal review overhead. I have now been</div><div>involved in several reviews that involved API changes that were otherwise unremarkable</div><div>and primarily motivated by modernizing and style:</div><div><br></div><div>* <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0040-attributecolons.md" target="_blank">Replacing Equal Signs with Colons For Attribute Arguments</a></div><div>* <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0039-playgroundliterals.md" target="_blank">Modernizing Playground Literals</a></div><div>* <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0034-disambiguating-line.md" target="_blank">Disambiguating Line Control Statements from Debugging Identifiers</a></div><div><br></div><div>To this list, you could add:</div><div><br></div><div>* <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0053-remove-let-from-function-parameters.md" target="_blank">Remove explicit use of let from Function Parameters</a></div><div><br></div><div>Each of these proposals could have proceeded with a simple "any objections" sanity check </div><div>discussion period rather than a more formal full review. As a another example</div><div>(<a href="https://github.com/apple/swift-evolution/pull/256" target="_blank">now unnecessary</a>), consider the `dynamicType` keyword, which would have required</div><div>a formal proposal to be modernized into Swift's lowercase keyword standard.</div><div><br></div><div>The hallmarks of these changes are:</div><div><br></div><div>* They have limited impact</div><div>* They increase language consistency</div><div>* They are uncontroversial, offering simple, straightforward, and correct changes </div><div> that have already passed review in spirit, if not in letter</div><div>* A preponderance of reviews are "+1" rather than in-depth discussions of why the proposal </div><div> should or should not be adopted.</div><div><br></div><div>I would recommend retaining a change document requirement for these proposals.</div><div>This would be similar to a brief but formal proposal, that lays out the justification, </div><div>detail design, and any associated background info for the change. Doing so</div><div>would provide a historic record of the change and any notes from the team, and be </div><div>in a form that would support the extraction of key details for use in release notes.</div><div><br></div><div>I do not know whether these would need to be grouped and numbered with the normal</div><div>proposals or placed into their own numbering scheme.</div><div><br></div><div><b>STYLE TWO: Fast tracking viability</b></div><div><b><br></b></div><div>Once a draft has been discussed on-list and submitted as a pull request, I would like to</div><div>see a biweekly (or even once-a-month) <i>Pull Request Review</i> meeting from the core team</div><div>where a review groups looks over the current pull-request queue and scores them: </div><div><i>recommend close</i>, <i>recommend promote</i>, <i>needs work</i>, <i>defer past 3.0</i>.</div><div><br></div><div>This approach:</div><div><br></div><div>* Would offer closure to proposal authors who are otherwise unsure of the viability</div><div> of their proposals</div><div><div>* Naturally happens after a significant on-list discussion/pre-review period has already </div><div> taken place</div></div><div>* Would allow the team to weed out proposals with significant issues before entering</div><div> formal review</div><div>* Would allow on-list reviews to give precedence to only those proposals that make sense</div><div> both in the time context of Swift 3.0 and its overall design philosophy. </div><div><br></div><div>Swift is an opinionated language. This review style would introduce discernment and</div><div>feedback slightly earlier in the process without stifling on-list discussion.</div><div><br></div><div><b>A few final thoughts</b></div><div><b><br></b></div><div>It is a given that Swift 3 is going to be the last opportunity to make large, code-breaking</div><div>changes to the language. With that constraint, I'd like to see more time and effort go into</div><div>improving Swift's fundamentals. Any time, effort, and review that can be better spent</div><div>getting collections and indices right rather than worrying about colons and casing is,</div><div>in my opinion, worth a tradeoff in community control. </div><div><br></div><div>The natural tension between engagement and coherence requires a balance that serves</div><div>the entire Swift community. Open evolution processes are, by nature, chaotic. Maintaining</div><div>a coherent vision for something as complicated as Swift requires coordination and leadership. </div><div>That's why the ultimate responsibility for adopting changes lies with the Swift </div><div>core team, which establishes the strategic direction of Swift. </div><div><br></div><div>I hope by adopting these fast-track review styles that the Swift open source community </div><div>can better focus on the big updates while making sure that the small details are attended to</div><div>carefully and thoughtfully without overwhelming the process.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-- E</div><div><br></div><div><br></div><div><br></div></font></span></div><br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div></div>