Feedback on proposal acceptances

:100: Can't agree more! I wouldn't waste so much energy promoting "explicit shadowing" angle so hard during the pitch review if I knew that position of the core team! (as I sincerely believed and continue to believe that making shadowing explicit is a good thing, but totally fine if that's just me).

1 Like

Ditto, @tera. Like I said before, I value a lot my time, just like yours and everyone else's. A simple sentence like that in the proposal review would have been even better.

1 Like

Then, what's "clear majority", is that 75% or smth? I thought it would make sense to have this voter selector on top of the thread:

  • very pro
  • somewhat pro
  • somewhat against
  • very against

probably too late now.

2 Likes

@Matt_McLaughlin: My worry here is that accepting such polarizing proposals changes the calculus in undesirable ways and will lead to more polarizing proposals making it all the way to reviews.

This is an interesting point. Just to be clear, Matt, is your concern that polarizing proposals are inherently costly for the community because they necessarily leave some participants with a sour taste? And that they might be better avoided entirely, much as one might avoid discussing politics or religion at a dinner party?

If so, I really can't disagree. Community is precious, and there's only so much goodwill to go around. I'm happy to have if let foo in the language and will use it. But I agree that it's not an important change, and I'm not sure that rolling this boulder all the way uphill was worth the cost in terms of person-power and friction.

But in the proposal's defense, this degree of polarization seems to be pretty rare in the history of Swift. I'm not sure it's useful as a model for general policy. And, I'm also happy that the issue is resolved and that we never need to discuss it again. I would have been equally happy in this regard if the proposal were rejected.

2 Likes

I wasn’t very happy to see the phrase “The clear majority of responses to the proposal were in favor” in the motivation. My position was “-1 we shouldn’t solve this problem at all”, but I felt that @xwu and @wowbagger had covered my arguments well and didn’t want to spam, so I didn’t say anything.

But @jayton, if you didn't vote or comment, you can't reasonably complain that your perspective wasn't reflected in the tally.

Just as a point of fact, the clear majority of responses were in fact in favor of the proposal. That doesn't necessarily mean that the proposal should have been accepted, but it is an accurate statement.

3 Likes

For the record, I did the calculation myself I've got much bigger counts... (yes, i was uniquing posts to people and accounting for a few people changing votes). The result ratio was also different (still with about 60% or 65% of "pro" voters, so that was an indisputable majority, although not overwhelming in my view). I must admit that wasn't a trivial task to do the count, hence the idea of an automated vote selector.

3 Likes

This is tricky. An alternative would be to simply not acknowledge the volume of feedback on either side. Since reviews are not votes, perhaps making no mention of the weight of ayes and nays would be better, but I expect that would also lead to consternation from some reviewers when they don't agree with the decision.

We can also go about counting :heart:s on posts, and whether a heart on the review launch post counts as indication of being "in favor". We have been down this road before. The answer there is the same. The core team evaluates the substance of the arguments for and against, not the number of them.

This review is an interesting case because the proposal has a lot of popular support outside of Swift Evolution. Some well-known developers even pointed at the review thread and encouraged developers who might not normally post to evolution to voice their support.

If @chockenberry had not done this, it is quite possible that the against posts would have outweighed the for posts. If so, should we have not accepted the proposal? No, the outcome should have been the same. What matters is the arguments presented, not the volume of feedback. This is what the review manager weighs and reports back to the core team, and what drives the decision. Ultimately, the core team agreed with the strong case made by the proposer, and did not find the points made against sufficient compared to the benefits.

Despite the fact that it led to a number of "voting" posts, I'm also grateful to Craig for highlighting this proposal to a wider variety of potential evolution participants, increasing the diversity of opinions on the pros and cons. This touches on a final point on why proposals are not votes: participants in evolution are a self-selected group of people who dedicate their time discussing the evolution of the language, and are willing to engage in public discussion.* This is great, and we get immense value out of this community challenging and riffing on proposals. But whether this group is a true representation of the wider Swift community is unknown. Note I am not saying it is unrepresentative. We honestly do not know if it is – and maybe it doesn't matter. What matters is that reviews discussion flush out all of the things to consider about a proposal, good and bad, as well as surface alternatives that might be better, and help the core team decide what is the best thing for Swift going forward.

* a reminder to anyone who feels uncomfortable posting in public: if you want to give feedback on a proposal, you do not need to post it to the forums. The review manager will take feedback via DM or email as well, and incorporate it into the core team process. If that feedback affects the decision, they may ask to post it anonymously.

29 Likes

Thank you for your response @Ben_Cohen. I would also like to thank everyone that engaged in this particular discussion I brought up without even having properly articulated my thoughts and feelings. With your help I was able to understand what made me discontent about this proposal acceptance and rationale.

I already mentioned the value of time before, but I would like to mention it again because I think I'm now able to properly articulate my thoughts around the current topic, and they mostly revolve around the sentence above. It is about the value of time and the willingness to engage in public discussion.

Personally, I have great difficulty engaging in discussions in this forum. First, because of the language. English is not my native language and, while I use it daily due to my work, I still don't feel I can express myself the way I would like to. There is also the risk we assume exposing our ideas publicly. The risk of expressing an ideia that is not even worth being mentioned, like @Douglas_Gregor said here:

I feel that the rationale of this particular proposal did not provide the utmost respect it could have for the time and willingness to engage in public discussion that some have put into the discussion.

I also think that this "guideline" was not respected, in this particular case, since the sentence below could have come up much sooner during the review.

Thanks again everyone for engaging in this discussion. :pray:

In general, my experience has been that if a suggestion is made, or made repeatedly, in a pitch or proposal review, and the suggestion doesn't gather much support or engagement from others, then it is probably not a suggestion that most others think is a direction to pursue.

Even without a statement from the Core Team about a particular suggestion, seeing how the suggestion is received by others on the thread is usually a decent indicator of community interest or support for the suggestion.

2 Likes

I think this is the most important thing about this meta discussion. Maybe is just me but I would love for acceptance posts to sometimes have a bit more text, specially when a proposal has hundreds of comments. I know we're picking in this specific instance, and in the grand schema of things is not a big deal, but is just something I would like to see. Maybe a bit more of summary of what happened during the review process. Of course writing is not your job so I understand this is a big ask.

I think what is bothering to some people here is that one side of those argument, even if didn't have enough volume, wasn't mentioned in the acceptance, making it feel (because we know is not true) that it was ignored.

Specially when you consider the following

Ultimately we're just here to provide feedback not to decide. It's just nice to feel that you have been listened. And even if deep down we know we are, maybe is worth putting a bit more effort on that. It's never nice to see people in these forums feel bad because they don't feel listened.

Ultimately this hasn't been a big deal imo, but I just wanted to take the opportunity to raise it since it can have a long lasting impact if this feeling grows. I respect and love the work the core team, review managers and proposal authors do :heart:.

PS: one last point, I still think that the hearts should be considered a list a bit. Personally there is plenty of times I don't want to add more spam when somebody else has written my thoughts already. I know, this goes again to the point of what matters are not the votes but the arguments themselves... but that's a bit lost in translation when then we hear things like "overwhelming positive".

6 Likes

On the “anti-heart” side, my default mode is pretty much to “heart” any post by someone taking the time to engage in discussion with points that I’ve raised, without much concern for whether I agree with the arguments they’re making. I use the heart as more of a “thanks for participating in the discussion with me” rather than a “vote” for the arguments raised.

8 Likes

Perhaps such a laundry list could be seen as a summary and posted at the end of the review thread for folks who are interested in the arguments raised during the discussion and who are generally interested in the evolution of the language. I am aware that this would likely require more time from the review manager, but if a list of points made during the discussion is already considered, it would be nice to be posted for the others to see :slight_smile:.

1 Like

Yes that's totally fair. Everybody uses these things differently ^^

3 Likes

IMHO that would make language stronger, even if it's not the current tradition among other languages. Got this bug just now, explicit shadowing intent marker would have caught it:

var sum: Double = 0

if let samples = ... {
	sum = values.map ...
	value = sum / values.count
} else if let samples = ... {
	let sum = values.map ... // 🐞
	value = sum ...
} else if let samples = ... {
	sum = values.map ...
	value = sum
}
use(sum)

Given that the language supports shadowing and won't stop doing so (this has been clearly expressed), the answer may well be a linter that would emit a warning for all shadowed variables.

1 Like

That example is also a good candidate for using an unset reference (or whatever it's called) rather than a mutable value.

let sum: Double
let value: Double

if let samples = ... {
	sum = values.map ...
	value = sum / values.count
} else if let samples = ... {
	let sum = values.map ...
	value = sum ...
} else if let samples = ... {
	sum = values.map ...
	value = sum
}
use(sum)

That way you'd get an error about an unset value, as the compiler has checked all of the paths for you.

6 Likes

I believe the term you’re looking for is “uninitiated constant”. :)

1 Like