<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I agree, this makes focusing on the right types of changes much easier and helps us avoid turning Swift into an incoherent conglomeration of random use-cases (*cough*, C#, *cough*).<div class=""><div>Now, the question is: when will be the time to officially push the factory initializers proposal and which stage should it be targeting?</div><div><br class=""><blockquote type="cite" class=""><div class="">On Jun 12, 2017, at 12:06 AM, Xiaodi Wu 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="">I think there is merit to the current system, although it can be annoying.<br class=""><br class="">I’m sure we can all agree that a properly submitted and approved proposal should have solicited the fullest possible feedback at each stage, including the initial pitch stages. Based on the experience of Swift 3 evolution, however, it’s clear that there is limited bandwidth for participants to engage fully with all possible topics.<br class=""><br class="">The innovation of defining priorities for each phase has really helped to bring about a more manageable process for everyone, I think. If a proposal is not in scope, then participants don’t (and shouldn’t) feel like they miss an opportunity to help shape a feature by sitting out the conversation. Therefore, by definition, any such out-of-scope conversations will not get the fullest possible feedback from community when it is pitched, and it should go through the pitch process again from the beginning if the aim is to progress to the next stage.<br class=""><br class="">Otherwise, you’re basically exempting the initial pitch stage from the parameters of what’s out of scope, defeating the purpose of that innovation.<br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Sun, Jun 11, 2017 at 15:48 Daryle Walker via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">I’ve read about the Swift developers taking certain kinds of proposals during certain phases (Swift 3, Swift 4 stage 1, Swift 4 stage 2, etc.). So if someone writes a proposal that isn’t of the type of the current phase, it’s auto-rejected. Is it possible to set some kind of proposal queue so their authors don’t have to guess when it’s the right time to resubmit?</div><br class=""><div class="">
<div style="letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; word-wrap: break-word;" class=""><div class="">— </div><div class="">Daryle Walker<br class="">Mac, Internet, and Video Game Junkie<br class="">darylew AT mac DOT com </div></div>
</div>
<br class=""></div>_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</blockquote></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>