Interestingly, the "feels Swifty enough" is an aspect that I do consider. I haven't quite formally defined that metric for myself yet, though. It may be one of those things that are easy to understand, but are difficult to describe. Or I may be way too pedantic when it comes to large-scale community-driven technical discussions.
I see the merit in hearing these "vibes"-based opinions. At the very least, not all people are willing to express their opinion in the first place, much less spend the effort it takes to polish an opinion into a rational argument. This is what I imagine you meant by "overly restrictive" and I agree. I merely hold myself to that standard, I don't necessarily expect everyone to do the same.
I'm just relying on the LSG's best judgement regarding (to put it bluntly) which kinds of feedback to pay how much attention to, treating subjective opinions as less relevant than rational arguments. So far, I haven't seen any decision that LSG made that was significantly contradicting rational reason, so I don't feel like questioning their decision-making now is necessary or fair. At the end of the day, even the type name Vector versus InlineArray was highly contended and there were more objective arguments in favor of InlineArray, than Vector (which I'd summarize as mostly "I've seen it somewhere else, so I'm fine with it").
I think as someone whose time spent on these forums is unpaid, my question is always is participation worth it? There are lots of fun and worthwhile things to do in the world.
I'm cool with things not be a vote. Cohesive vision matters. Forums are a non-representative subset, etc. etc.
So what should my take away from this dialog be? If I have a finite window of time to spend on the forums, is it more worth my time (time to community impact ratio, time to personal development ratio) to chime in on the proposal or the pitch? Are either of them even worth it at all*? Should I focus on answering questions... etc.
to clarify folks have already indicated that the comments are read and that the evolution process is not just engagement theater. The worth it is TO ME in terms of evolving my own thinking, not to the group!
There have been instances—too many to count, really—where a single comment during either the pitch or proposal review has led to major changes. Where some proposal intersects a use case for your personal or professional projects, this means that a timely reply can make a major difference to you and to the community.
The review manager's role includes making sure such concerns are captured and addressed, and the process not being a vote means that even thousands of existing replies (although, from a self-preservation standpoint, I hope not) is no barrier to your contribution making a difference. We really mean it when we say that feedback during this process helps to make the language better.
In one of my favorite examples, dozens of posts back and forth debated whether isDivisible(by:) ought to be spelled isEvenlyDivisible(by:) to correctly capture the integer-based semantics. As soon as someone dropped in to suggest isMultiple(of:) the discussion quickly converged on this seemingly obvious choice which everyone else had somehow missed.
Okay, that makes sense, but then why mention it every time if it is not part of the decision making process?
It does not seem a stretch for us to read such a comment about feedback and take that to mean “the feedback was mostly positive [and that sentiment factored into our decision]”.
I’m not suggesting hidden meaning - I’m suggesting from the context it implies meaning, especially to those of us here who have no indication whether their sentiments are taken into account, except to see the review decision.
Without in any way speaking for the LSG—it is quite possible that negative or positive sentiment is taken under consideration, but is not dispositive. For example, a hypothetical LSG member might note that prevailing sentiment is against a given change, but not feel that an alternative is available that seems better to them, all things considered.
Yeah I hope that is the reasoning here, and that we could see further clarification of how they take such sentiment. @xwu’s comment seemed to me to suggest it was mere observation but that seems a little odd given its consistent mention in review decisions.
I also agree with the general just that reasoned arguments and alternatives that provide solutions are significantly more important and valuable than general sentiment.
Some of the comments above have seemed to downplay the observation of sentiment, especially in the context of this coming to review despite a strong negative sentiment, and it would be enlightening to get a specific read on the value this plays in deliberations.
If it is considered as a factor and valued, but is not seen as dispositive, this tracks with how I’ve been reading it, but it should be clarified how sentiment affects things before review, and then at review, as this has clearly taken people off guard.
If it is not a factor, that would be helpful to know as the comments from the LSG would seem (admittedly via inference) to indicate otherwise.
Either way, I think clarifying the position here would be helpful to those on the outside to understand the reasoning and how our comments are taken.
I mean, it’s a pretty good summary of the feedback on most proposals. Even when there’s something more specific to talk about in the decision, the feedback was usually still highly positive about the overall proposal — there were just questions about a specific method name or something like that. We still really appreciate that feedback, and we don’t want to let it go completely unacknowledged, even if there isn’t much more to say.
I honestly believe that everyone deserves their voice to be heard. I also think that pitch proposals get more overlooked by the broader audience, unlike actual review threads. Even tho I'm against the proposed syntax sugar I still strongly believe that this proposal was worth to get into review
I agree that it's desirable that any proposals can come to review, because no proposals would be accepted nor even rejected without official review state.
On the other hand, as for SE-0483, I suspect the reason why some folks surmised that there were biased things was because one of the authors of the proposal was at Core Team and Language Steering Group.
By the way, Testing Workgroup recently showed some principles of reviewing proposals written by workgroup participants.[1]
I wonder if such rules could be applied to other groups not to incur groundless suspicion.
At the end of the review, the LSG will discuss the proposal and decide what we think the right thing to do is.
For me, it would be incredibly valuable and interesting to be able to view a video recording of LSG discussing a pitch. I’m curious how you do it!
This whole thread seems to be calling for transparency into LSG (and maybe even Core Teams) decisions making, so why not video recording LSGs pitch discussions and put them online?
Apart from transparency, I think it would be an excellent learning opportunity for at least me.
During the years I’ve been consuming (and sometimes “producing”) Swift Forums I’ve learned so much not only about Swift and programming languages in general, but I also think I’ve become a better coder.
The collective wisdom of the LSG is vast and I would like to take part in your pitch discussions - is that something you can pitch (pun intended) to the rest of LSG?
On the subject of recusing oneself from one's own proposal, this would not change much as a formal mechanism, because the LSG works by consensus, rather than voting.¹ So it's not possible that Ben would end up being "the tie-breaking vote" on this proposal in a Supreme Court scenario--if one person's vote decides the outcome, then we don't have consensus, and the proposal would be rejected or returned for revision.
Actually, now that I write it down, it can make the difference, when one of us would be the sole vote against their own proposal, which actually happens more often than you'd think (bulk of the LSG is basically ready to accept, until the author calls out an issue that they'd like to bring the proposal back to review to iterate on).
This is--to me--a more interesting principle from that thread:
When a review topic is underway, workgroup members whose proposals are under review will hold back in immediately responding to feedback, but take some time for the community to discuss first.
I'm torn about this. Broadly I think it's good for proposal authors to try not to respond to review posts right away, whether they are LSG members or not (for their own well-being, more than any other reason: two weeks is a long time to feel like you're on-call for responses). However, it's also pretty common to see posts that are simply misreading some aspect of a proposal, and sometimes the author can clarify an issue quickly that would otherwise snowball into a large discussion that doesn't actually relate to the proposal at all.
¹ we sometimes do an informal straw poll to see where people are in a discussion, but actual decisions are made by consensus.
I for one am happy that the proposal was put to review. Even though the proposed syntax immediately jumped at me as an obvious no with a bunch of rational reasons for it, I felt that it's not enough to reason about why the proposed syntax is a bad idea, and it would be more valuable to at least try to think of a better alternative and explain why and how it's better.
As a result, this led me to discover a potentially very powerful syntactic construct, which could be used as the basis of the proposed syntactic sugar, which in turn would be merely a single use case for the construct among potentially many.
I'm sure I'm not the first person to think of this, but regardless, this wouldn't have been possible if the proposal wasn't published for review to spark a passionate desire to prove it wrong and come up with something far superior .
This is an extremely important point. Evolution participants are a self-selected group that do not necessarily represent the wider community. Many proposals have gone through review, received majority negative criticism on the forums, only to be welcomed by the Swift community at large.
This is why the steering group requests all posts describe their reasoning. If you want to vote, there is a heart button. But number of hearts is not used as signal.
I must also add that on this recent thread, I have been very disappointed in the aggressive tone of some commenters. Describing proposals you do not like as, for example, "unserious" does a huge disservice to the process.
One of the reasons many Swift users rapidly nope out of discussions on the forum is the angry nature of some of the posts. I think for the most part the evolution threads are pretty civil for an Internet forum. But there in all reviews the seeds of things going off into ranting territory. For example, volunteering that you are "very strongly opposed" is, similar to voting, not helpful. Describing why you disagree with a proposal, or a post for or against it, and doing so respectfully and in a way that can be engaged with constructively (rather than being a frictionless surface of vehement but unreasoned opposition), is the best way to have your viewpoint influence the outcome.
I am sympathetic to this perspective, especially for the persons posting the proposal. This is why I tried to come up with something more than a description of my gut feeling when commenting on the topic.
However, the x syntax evoked a similar reaction from me along the lines of looking/feeling “unserious” or “silly”. I understand that it’s not very constructive and can make for an unwelcoming discussion. But, it was my first reaction, it’s my continued feeling about the topic, and seeing similar sentiment reflected in other’s responses somewhat validated that angle for me, even when I cannot articular it any better than that.
If you understand it's not constructive and that it makes for an unwelcoming discussion, I'm at a loss why you're defending it. And my ask is, please don't. Remember, if you can't find a more constructive way to put something, it is OK just to not comment. Especially when that view is already expressed in the same thread. Often this boil down to wanting to express a vote "with force". These "forceful" votes don't add useful signal to a pitch or review.
Many ideas expressed on evolution might seem unserious. In particular, the "no bad ideas in a brainstorm" ideating on naming often comes up with ideas that I might personally find "silly". But it's really important for the health of the discourse on these forums that people remain respectful and not say "that's a terrible idea" even if, on the face of it, the idea might seem terrible to you. If it really is terrible, don't worry, that will be clear to the LSG. On the other hand, if it isn't clearly terrible, you throwing that around isn't helpful.
At the same time, we are all human. I'm sure if I reviewed plenty of my old posts, I'd find myself saying some things that if someone else said them, I'd bristle. And that's fine. What's not fine is not taking that feedback on board.
Ben, nobody has called the proposal itself unserious. We (Florian and I) said that we disliked the specific syntax x because we felt that using a letter to approximate a symbol felt unserious. At least that was my reason.
You obviously don't agree, but it is a valid viewpoint, and I stand by it.
This is why I've chosen to be more pedantic when it comes to technical reasoning than may be necessary, because finding the right amount in a discussion is very difficult, and having too much discipline is (in this case) better than having not enough.
EDIT:
Yes, I feel the same way about the syntax x feeling unserious, I just chose not to frame it that way in my messages.
I don’t like those comments and I avoided making one like them in the main topic because I, too, cannot articulate it any better. Still, there can be a valuable kernel of feedback in these comments.
Especially in the case of the InlineArray type shorthand, it’s mostly a discussion about style and less of technical nature. This is where the decision will affect all people using the language, not just those implementing it, as perhaps compared to a more low-level discussion.
The LSG is a fairly specific set of Swift users. I could imagine most of them being used to the x syntax from LLVM and thus not anticipate the broader reaction from Swift users. I am not saying that that is the case, it’s just an example for a blindspot that the LSG could have and thus misjudge a style-leaning proposal such as this one.
I appreciate the work you do and understand the mental strain some of these comments can evoke. These comments don’t have to count as votes and I don’t expect them all to get replays. Only consider them a preview of the reactions when releasing a new version of Swift with a proposal implemented.
I’m not even sure that the operator-like nature is what makes the syntax feel unfitting or if it’s more the single-letter next to another identifier. But that is best discussed on the other topic.
I think the big problem here isn't that a large proportion of the community hates x; that could be true and it still be the right choice. I think the big problem is that we had this massive discussion about it in the pitch thread, and the proposal then came to review with
barely any mention of the dissent at all
no mention of what makes x a better choice than any of the other popular options
For better or worse, Swift evolution is driven by a small set of almost-all Apple employees, who wield enormous power — power more than enough to make a mockery of the idea of the community-driven "evolution process". And maybe I'm projecting, but I think that a lot of us here on the forums have a story of a proposal where we felt we had serious and legitimate objections, that were ignored or glossed over during a proposal review, maybe particularly in the months leading up to WWDC.
Assuming that the people here with the power to do so care about the perception of the evolution process, I think some changes would help:
When a proposal comes to review or is approved, it should include a section covering specific dissent from the pitch or review thread. Sometimes this already happens, but ensuring it's formalized and complete would help a lot. Everyone wants to know that their argument was heard, and wants to understand why it was outweighed.
"WWDC features" should have a (privately enforced) submission deadline that allows for an extended community review before they appear in June. Apple can't (be seen to) be throwing their weight around, if this process is to be truly collaborative.
Right now, evolution is driven more by "paid contributor wants a feature" than by "the community agrees that the language needs a feature"; some kind of "community incubator" process which assigns paid contributors to popular community proposals which would otherwise go un-championed and un-implemented, would make this feel a lot more collaborative.
Ultimately, we're putting a ton of energy into keeping pace with these proposals, and a ton of unpaid work into reviewing them. Feeling ignored feels bad, and it should surprise nobody that intense emotions result.
