[swift-evolution] Reflecting updated feedback was Re: [Review] Require self for accessing instance members

Erica Sadun erica at ericasadun.com
Wed Dec 16 17:58:56 CST 2015 

> On Dec 16, 2015, at 4:51 PM, Dave Abrahams <dabrahams at apple.com> wrote:
> 
>> 
>> On Dec 16, 2015, at 3:41 PM, Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Changing the topic hopefully to take some of the burden off Doug sorting through this thread. 
>> 
>> My for-loop proposal was heavily commented upon but to a lesser degree than this one. If you recall, I ended up with a shadow update on gist to address major concerns: https://gist.github.com/erica/56d533b75d0a36e3908f <https://gist.github.com/erica/56d533b75d0a36e3908f>  I don't think that was an ideal solution but it certainly helped. Having been through this, I have some rather strong feelings about the proposal process and I'll try to condense them here as a starting point to discuss these things.
>> 
>> * I wish ideas could go through initial vetting before they appear as a formal on-list [Proposal].  
>> 
>> Ideally, it would be great to pitch the team with a [Pitch] and see if the pitch has a chance. The downside is that the Swift.team has enough on their plate to deal with. It may not be feasible to do this. That said, the sooner you can get a sense of the pitch's health the better:  Is the pitch not worth pursuing, better suited for bug report system, worth pursuing but not for 3.0, or worth pursuing?
> 
> I think this is a great idea.  The main challenge would be managing expectations w.r.t. the detail of feedback.  To truly take the burden off the core team, proposers would have to be willing to accept a simple multiple-choice answer with no additional detail, without feeling insulted.  I think if people knew there was a way to ask for more detailed discussion (as in your next bullet), this might be possible

[ ] Not worth pursuing
     [ ] Not technical feasible
     [ ] Not suited to Swift
     [ ] Needs a much more compelling pitch to be considered at this time
     [ ] Other (unspecified, sorry, but we are overwhelmed)
[ ] Submit to bugs.swift.org <http://bugs.swift.org/>
[ ] Consider for 4.0 or later
[ ] This sounds like it's worth developing further.

Better?

> 
>> * If your idea is not fully formed, it would be nice to just have a discussion about it and not call it a proposal.
>> 
>> An idea that starts out, say, as an enhancement for initialization may turn out to be better suited by Swift adopting language features from existing modern languages. A discussion without being tied to a specific proposal gives you the freedom to explore, find, and develop the idea before starting the costly process of proposing a formal language change. Consider [Request for Discussion].
> 
> Yes, we definitely need some kind of RFC as part of the process/culture.
> 
>> * You may want to test the idea's temperature before starting the formal proposal process
>> 
>> As I learned, Survey Monkey is free and is a good way to quickly test the crowd.
>> 
>> * It helps to differentiate a preliminary "proposal", like Matthew Johnson's original protocol naming one, from one that's ready to submit for potential review. It went through significant updates before being ready to submit as a pull request.
>> 
>> I don't know what you'd call it, but maybe [Proposal Draft} would be a better subject for discussing and refining an idea.
>> 
>> * Once you're ready to propose, you'll probably want to incorporate the draft discussion. That discussion may not reflect the feelings of the entire mailing list, which is what happened with the `self` proposal. The entire list wasn't really invested until the actual review period opened.
>> 
>> Allowing the proposal author to update the proposal with *major* feedback and tweaks should be a part of the proposal process, and can be done via pull requests to the evolution repo. However, that requires Swift.team time and demands. You may just have to update on a gist to save them the extra work.
>> 
>> Also: It's unreasonable to expect updates on every complaint or support but if the proposal has already made it through a straw poll, and initial draft discussions, it's probably not going to have as much push back as this one did.
>> 
>> Okay, that's my suggested starting point. What do you think? 
>> 
>> -- Erica
>> 
>> 
>>> On Dec 16, 2015, at 4:15 PM, Nick Shelley via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> Creating that summary seems like it would be a large burden to place on whoever manages the review.
>>> 
>>> I imagine this would be done by the community through pull requests. If someone doesn't feel like their point of view has been accurately represented in the proposal, they should make a PR that changes that.
>>> 
>>> I don't think that that is worth the effort when the responses *are* readily available.
>>> 
>>> Readily available and easily consumable are two very different things. I'd guess that everyone voting on this proposal read or at least skimmed the proposal, but I doubt many of those who didn't follow the thread from the beginning looked at much of the mailing list discussion. (That's based on what I would do, so maybe it's not a fair assumption.)
>>> 
>>> On Wed, Dec 16, 2015 at 3:47 PM, T.J. Usiyan <griotspeak at gmail.com <mailto:griotspeak at gmail.com>> wrote:
>>> Creating that summary seems like it would be a large burden to place on whoever manages the review. I don't think that that is worth the effort when the responses *are* readily available.
>>> 
>>> On Wed, Dec 16, 2015 at 3:09 PM, Nick Shelley via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> All of the prior swift-evolution commentary on this proposal (which is nearing the 100-message mark) will also be considered, of course!
>>> 
>>> It is my opinion that the proposal should encapsulate as much of that discussion as possible so every reviewer doesn't have to read every comment in that thread. The current proposal is wildly one-sided and seems to only reflect the opinion of its author and those who agree with the proposal. I created a Pull Request (https://github.com/apple/swift-evolution/pull/59 <https://github.com/apple/swift-evolution/pull/59>, still not merged and no comments as to why) to more fairly represent the single counter-argument pointed out in the proposal, but others in the mailing list expressed concern that none of the other downsides of the proposal are represented at all.
>>> 
>>> Is my (and others') desire to have the proposal contain an accurate representation of the main points of the community discussion off base? Is the main purpose of the proposal to be a sales pitch for an idea, even if it includes building up and tearing down straw-man versions of the arguments brought forth by the opposition? I'm asking with sincere curiosity because I can't seem to find a good description of the purpose of the proposal in my research of how the evolution process works.
>>> 
>>> Thanks in advance for clarifying these points for me.
>>> 
>>> On Wed, Dec 16, 2015 at 11:58 AM, Douglas Gregor via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> All of the prior swift-evolution commentary on this proposal (which is nearing the 100-message mark) will also be considered, of course!
>>> 
>>> 	- Doug
>>> 
>>>> On Dec 16, 2015, at 10:55 AM, Douglas Gregor via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> 
>>>> Hello Swift community,
>>>> 
>>>> The review of “Require self for accessing instance members” begins now and runs through Sunday, December 20th. The proposal is available here:
>>>> 
>>>> 	https://github.com/apple/swift-evolution/blob/master/proposals/0009-require-self-for-accessing-instance-members.md <https://github.com/apple/swift-evolution/blob/master/proposals/0009-require-self-for-accessing-instance-members.md>
>>>> 
>>>> Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at
>>>> 
>>>> 	https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>> 
>>>> or, if you would like to keep your feedback private, directly to the review manager.
>>>> 
>>>> What goes into a review?
>>>> 
>>>> The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
>>>> 
>>>> 	* What is your evaluation of the proposal?
>>>> 	* Is the problem being addressed significant enough to warrant a change to Swift?
>>>> 	* Does this proposal fit well with the feel and direction of Swift?
>>>> 	* If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
>>>> 	* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
>>>> 
>>>> More information about the Swift evolution process is available at
>>>> 
>>>> 	https://github.com/apple/swift-evolution/blob/master/process.md <https://github.com/apple/swift-evolution/blob/master/process.md>
>>>> 
>>>> 	Cheers,
>>>> 	Doug Gregor
>>>> 	Review Manager
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> 
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> 
>>> 
>>> 
>>>  _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> -Dave

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151216/5eb93238/attachment-0001.html>

More information about the swift-evolution mailing list