[swift-evolution] [META] Fast Track Reviews

Jacob Bandes-Storch jtbandes at gmail.com
Mon Apr 18 12:21:40 CDT 2016

+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> 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
for the SEs. The SE-nnnn number in the proposal text could match the JIRA
number. Then the team could use custom JIRA workflows
and statuses
to track proposals more closely and make the internal process visible to
the community.


On Mon, Apr 18, 2016 at 8:56 AM, Erica Sadun via swift-evolution <
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.
> *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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160418/5e3ef946/attachment.html>

More information about the swift-evolution mailing list