I support everything Jon wrote. +1 Free-for-all brainstorming venue separate from focused proposal discussion.
+1 Working groups when helpful. +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). P > On Jun 12, 2017, at 9:16 PM, Jonathan Hull <jh...@gbis.com> wrote: > > >> On Jun 12, 2017, at 5:12 PM, Ted Kremenek via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
