<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I support everything Jon wrote.</div><div class=""><br class=""></div><div class="">+1 Free-for-all brainstorming venue separate from focused proposal discussion.</div><div class=""><br class=""></div><div class="">+1 Working groups when helpful.</div><div class=""><br class=""></div><div class="">+1 Longer public incubation for unstable / experimental features (but that idea executed & communicated with caution, preferably with active support from the compiler for preventing careless dependance).</div><div class=""><br class=""></div><div class="">P</div><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 12, 2017, at 9:16 PM, Jonathan Hull <<a href="mailto:jhull@gbis.com" class="">jhull@gbis.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 12, 2017, at 5:12 PM, Ted Kremenek via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">- 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.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">I would also like to see a place where ideas and known issues can be organized and referenced.</div><div class=""><br class=""></div><div class=""><i class="">A structure that has worked well in member-driven organizations I have been a part of in the past is that of working groups</i>. 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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">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.)<br class=""></blockquote><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">I agree. Do you have specific thoughts here on what could be done differently?</span></div></blockquote></div><br class=""><div class="">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.</div><div class=""><br class=""></div><div class=""><b class="">Unstable</b> - This is actively under development/design and should be expected to change. It is not safe to build frameworks on top of this.</div><div class=""><br class=""></div><div class=""><b class="">Pre-Stable</b> - 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.</div><div class=""><br class=""></div><div class=""><b class="">Stable</b> - 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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Jon</div></div></div></blockquote></div><br class=""></body></html>