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

[Jonathan Hull]

> On Jun 12, 2017, at 5:12 PM, Ted Kremenek via swift-evolution <swift-evolution at swift.org> wrote:
> 
> - Sometimes (often?) refinements aren’t part of a grand design.  They evolve in the mind space from usage of Swift.  In other words, greedy optimization is sometimes just a natural way discussion and design happens.  The question in my mind is when these concerns come up should we throttle individual proposals and take more time to take a broader view?  Maybe that’s the answer.  Having been in discussions in the Core Team meetings I can say that sometimes it is clear there is a broader topic to be discussed, and other times it isn’t.

I would like to see an explicit place (maybe another list or a section of the eventual discourse) where we can ideate.  Ideation requires a less critical environment than this list has been able to provide, and I think it has been contributing a great deal to our inability to deal with the larger picture.  The exception to this are the manifestos provided by the core team, which I would guess are a result of off-list ideation sessions, followed by concentrated refinement.

In the absence of an official place, it seems that there are a lot of ad-hoc places where this is being done in a fragmented way.  The issue with this is that, when I see “We had a long discussion on Slack”, I don’t know where this Slack channel is, how to get an invite (or even if I am eligible for an invite). Even if I have access to all of the places this discussion is happening, it is so fractured that going back to find important bits of a part of a conversation later is nearly impossible. 

I would also like to see a place where ideas and known issues can be organized and referenced.

A structure that has worked well in member-driven organizations I have been a part of in the past is that of working groups.  That is, we would larger identify areas of interest for the future development of swift (e.g. Strings), and then spawn a separate list or discourse section for deeper discussion (anyone who is interested could join).  The group’s mandate would be to work through the big picture surrounding that issue (including an ideation stage) and develop a resulting manifesto.  That manifesto should be an evolving document with known issues that need to be solved, and a record of attempted solutions which failed and the reason for their failure.

I think this structure would take some pressure off of the core team and allow deep thinking on important topics.  It would free the main list to focus on specific proposals based on the guideposts provided by the manifestos.  Discussions like the Great Access Modifier War would have been contained to a working group, with the main list only receiving a recommendation at the end.

>> Concern #2 is that it’s hard to know what to do with a proposal when the ideal answer is “we need to see how it plays out in practice and then decide whether to accept it.” Theoretical discussion untempered by practical prototyping is a great way for a group to talk itself into a bad idea. (This will especially be a problem with future work to build out generics & existentials.)
> 
> I agree.  Do you have specific thoughts here on what could be done differently?

I think we can partially solve this by having an extra stage of “stability” in our documentation.  Right now, things are either officially part of the language or they aren’t (with a very short beta period between WWDC and the Fall).  What I would like to see in the documentation is a notion of how sure we are of a particular piece of API or syntax.

Unstable - This is actively under development/design and should be expected to change. It is not safe to build frameworks on top of this.

Pre-Stable - We think we have a design which works, but we need to see how it works in the larger ecosystem before guaranteeing stability.  Anything built on this should be prepared for potentially large changes in the future, and be marked “Pre-Stable” themselves.

Stable - This has been extensively tested in the actual swift ecosystem and proven itself a useful addition.  Any changes to this in the future are guaranteed to either be source-compatible or have a full depreciation cycle. It is completely safe to build on.

I think being explicit about what we expect to change in the future, and having a notion of “stable” that is truly stable will give us a lot more freedom to experiment as well as room to fix our mistakes.

Thanks,
Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170612/c3cc6340/attachment.html>