[swift-evolution] [META] Fast Track Reviews

[Jacob Bandes-Storch]

+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
<https://bugs.swift.org/secure/BrowseProjects.jspa?selectedCategory=all&selectedProjectType=all>
for the SEs. The SE-nnnn number in the proposal text could match the JIRA
number. Then the team could use custom JIRA workflows
<https://confluence.atlassian.com/adminjiraserver070/working-with-workflows-749383109.html>
and statuses
<https://confluence.atlassian.com/adminjiraserver070/defining-status-field-values-749382903.html>
to track proposals more closely and make the internal process visible to
the community.

Jacob

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>