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

Thu Dec 17 19:22:37 CST 2015

Hi Erica,

Thank you! Some comments below...

> On Dec 16, 2015, at 3:41 PM, Erica Sadun via swift-evolution <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?

Pushing things into bug-fixes is the easy one of these, since that skips a more heavy-weight process for a lighter one.

The thing I like about your “[Pitch]” idea is that it indicates a willingness to hear “not worth pursuing”, which is generally a tricky social problem: it is very hard to convince someone that their idea is “not worth pursuing” (even “not now” can be difficult), and the core team absolutely do not want to come across as dismissive. That’s especially true because there are a ton of ideas that we *like*, but the need to focus on Swift 3 prevents us from engaging on them.

> * 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].

> * 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.

There’s a general theme here of being more clear about where a proposal is in the process. Right now, we have “pre-review” and “review”, but you’re looking for something to distinguish the “pre-review” state further: an initial, more free-form “ideas” state which is more about solving a specific problem, then a later “proposal draft” state that means we’re getting closer to the “review” state.

The benefit of having more states is that it makes it easier for people to jump into the process at the point where they get interested: one might not have time to consider all of the “ideas”, but would want to weigh in on proposals once they hit the “proposal draft” state and things are getter more specific and more serious. Indeed, this is the reason why we have the swift-evolution-announce list for reviews, so that more casual observers can see what’s made it to the last part of the process at which point it’s time to either weigh in or accept whatever happens.

The downside of having more states is that it’s more complicated for proposers.. start with [Idea], then go to [Proposal Draft], then create a pull request, then [Review]. That’s not necessarily a huge problem: it takes real work to produce a proposal that will go through the whole process already

> 
> * 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.
> 

I’m mixed on this. It’s so very easy to “+1” a partially-formed idea and then, when confronted with specific details and trade-offs, change one’s mind. I guess that’s fine if you’re going into the survey knowing that you’re getting very imperfect data, and that the “yes”’s that come in are fairly weak and entirely nonbinding.

[Note: I pulled the following sentence out of it’s original context, because it’s a separate thing I want to comment on…]

> The entire list wasn't really invested until the actual review period opened.

That’s actually an intentional part of the process. Some (many!) people won’t want to get involved until that [Review] e-mail comes through, because they don’t have the time to follow everything that’s going on, yet they care about Swift’s evolution. That’s a good thing in general, but it does mean that feedback comes late. Adding [Proposal Draft], as you suggest above, give another stage at which more people can jump in because the proposal has reached some intermediate point in its seriousness, so more feedback comes earlier. The benefit here is perhaps that the inputs to the actual [Review] process are more likely to end up being accepted, because more people paid attention earlier.

> * 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.

> 
> 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.

It’s human nature to want to present one’s proposal in the best light, so any attempt to incorporate the draft discussion will inevitably have some bias, and that’s okay. That said, listing counter-arguments along with responses to those counter-arguments in the proposal generally makes a proposal stronger, so it’s in the proposer’s best interest to do that.

	- Doug

> 
> -- 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
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151217/6779e44f/attachment.html>