+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 < [email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
