[swift-evolution] Swift phases and mis-timed proposals

[Xiaodi Wu]

On Tue, Jun 13, 2017 at 1:18 AM, Chris Lattner via swift-evolution <
swift-evolution at swift.org> wrote:

>
> On Jun 12, 2017, at 10:07 PM, Paul Cantrell via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> Perhaps the solution is not necessarily throttling proposals per se, but
> having some mechanism for routing a proposal to something other than either
> a review cycle or the freezer: “this needs manifesto-ing,” “this needs
> prototyping to measure impact on existing code,” “this needs to simmer and
> find its context before we work it into a proposal,” etc. (That’s related
> to Daryle’s original message.)
>
>
> I feel like I’m missing some part of the motivation for this thread.  Let
> me try to explain why:
>
> Lets say you’re interested in proposing a new feature or idea today, and
> are told that it is out of scope.  One of two things happen.  When the next
> release comes around, either:
>
> 1) if you’re still engaged with swift-evolution, you can bring it back up.
>
> 2) if you’re not still engaged, it will get dropped unless someone else is
> interested in championing it.
>
>
> What good does a “queue” of proposals in the freezer do?  In practice,
> getting a proposal to happen frequently requires editing and iteration, not
> to mention active discussion about motivation.  We have no shortage of
> important proposals to get through in each release, why should we make it
> easier for proposals with no active proponent?  Wouldn’t that just
> encourage people to drop off “drive-by” proposals for ideas?
>

I think this goes to the discussion above about what kind of list this is
to be. We've got, on the one hand, a significant number of proposals of the
following sort: how should indexing into the middle of a grapheme be
handled? which integer protocols should have the bitwise operators? These
require editing and iteration, as you say, and very active back-and-forth
discussion. These days it seems these sorts of threads rarely gain the
greatest attention. The most useful kind of feedback in such a discussion
would be a detailed and robust critique; much less useful is the ever more
common "+1," and storing the proposal in a freezer is the surest way to
irrelevance as the detailed design can quickly become nonsensical due to
even small changes elsewhere.

There are, however, a significant number of conversations that, at base,
are declarations that there exists some problem or issue. It's not
straightforwardly a bug that can be filed, and it's not a user knowledge
issue that can be solved by a question to swift-users, but it's something
else that may require a language change. This is, of course, a perfectly
understandable state of affairs for which some forum should probably exist.
However, the "format" of Swift Evolution requires a proposed solution and
detailed design, so the author feels compelled to put down _something_ that
might alleviate the problem. Frequently, later in the discussion, the
author will reply that he or she isn't actually married to the proposed
solution and/or does not really know if the detailed design will work at
all, but wanted the community to acknowledge that a problem or issue exists
and needs attention. Critiquing the placeholder proposed solution and
detailed design is kind of beside the point, even though it's the
ostensible purpose of this list. If anything is helpful in this scenario,
it would be feedback that validates and expounds on the issue (or in the
absence of that, "+1"). However, there's not an iterative process that will
take you from that point to an implementable design. It might be, however,
a topic that fits nicely into a "queue" of some sort.

There's another class of conversations that, from what I can tell, boil
down to a request for a feature--often one that is highly desired by many
people. The feature doesn't yet exist because it would require extensive
design and implementation effort. Perhaps the author is unaware that the
feature is already widely desired, or perhaps the author simply wants to
make it known that they wish that it would take higher priority. The actual
motivation for starting a thread isn't the promotion of any particular
design for the desired feature, just the feature itself. Also a perfectly
understandable situation, and should be accommodated in some form,
somewhere. However, Swift Evolution requires a detailed design, so the
author feels compelled to sketch out some sort of placeholder; sometimes,
the "detailed design" recites more and more elaborate variations of the
feature but makes no attempt to actually describe how it will come to be.
Again, little point in critiquing it. Again, there's not an iterative
process from there to implementable design. This time the topic is almost a
meta-discussion on the proper prioritization of items in the "queue" of
ideas, and the responses that are relevant to such a conversation (short of
designing and implementing the feature) can really only be "yes, I want
this feature too."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170613/6eba4b8f/attachment.html>