<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=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 8, 2017, at 12:08 PM, Kelvin Ma <<a href="mailto:kelvin13ma@gmail.com" class="">kelvin13ma@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Nov 8, 2017 at 1:58 PM, Ted Kremenek via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class=""><br class=""><div class=""><span class=""><br class=""><blockquote type="cite" class=""><div class="">On Nov 8, 2017, at 11:40 AM, Ted Kremenek via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class="m_6641731534315039332Apple-interchange-newline"><div class=""><div style="word-wrap:break-word;line-break:after-white-space" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Nov 8, 2017, at 4:30 AM, Wallacy via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class="m_6641731534315039332Apple-interchange-newline"><div class=""><div style="font-family:Helvetica;font-size:14px;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" class="">I do not agree with Ted that only a few projects should be ranked, everyone, as it is in npm should be available. Only be graded according to recommendations.<br class=""></div><br class="m_6641731534315039332Apple-interchange-newline"></div></blockquote></div><br class=""><div class="">I’m a bit confused. I’m not sure what comments of mine I’m referring to. </div></div></div></blockquote><div class=""><br class=""></div></span><div class="">Clearly I’m double confused. That meant to read “I’m not sure what comments of mine *you* are referring to”.</div><div class=""><br class=""></div><div class="">I fully support having a broad spectrum of libraries that the community builds and uses. Any library that we decide to make part of “core Swift” — IMHO at a mature point in a library’s evolution — would need to have high value to the majority of the community and would need to feel solid enough that we can lock it in for both source and binary compatibility, high quality of implementation with sustained maintenance, etc.</div></div></div></blockquote><div class=""><br class=""></div><div class="">i mean I don’t think these approaches are incompatible. The “swift core” could just make the process of independent libraries getting started easier. Like right now there’s really no place to say “hey I just started a library project for X, and anyone who wants to be involved should contribute at Y github repo where it lives right now”. I’ve tried sending that on this list before and it didn’t really work because mailing lists aren’t really a good medium for that and no one wants the swift-evolution list getting clogged with project-specific messages most people don’t care about. <br class=""></div></div><br class=""></div></div>
</div></blockquote></div><div class=""><br class=""></div><div class="">These are great points.</div><div class=""><br class=""></div><div class="">FWIW, I’m getting optimistic about moving to a forum soon. Would you expect that a forum could provide a better vehicle than a mailing list to arrange communication and interest within the community around building libraries? Not just doing shout outs for projects, but also doing possible API design review, etc.?</div><div class=""><br class=""></div><div class="">As an analogy, within Apple we have various mailing lists to review APIs, which is one mechanism used for different teams to co-review newly proposed APIs and consider how they compose together with other APIs. It’s not always perfect, but it does help facilitate a culture of API review so that various APIs can be considered together and part of the same (or compatible) design philosophies.</div><div class=""><br class=""></div><div class="">One of the things that resonated to me from Dave DeLong’s proposal was a sense about having a set of libraries that are well-considered and their efforts coordinated. While the coordination pitched in Dave’s proposal was about a focused effort on a particular set of libraries/features, coordination can also take the form of having a community that cares about building good APIs and can constructively discuss them. This can be done while also completely factoring out whether or not those APIs are part of “core Swift”. Further, shared API review wouldn’t necessarily be about making actual decisions — which is the case of swift-evolution when evaluating language and standard library changes — but offering advice. Fundamentally the library author still stays in control of their library and APIs, but the community could help in shaping up the gestalt of what are considered well-crafted Swift APIs in general.</div><div class=""><br class=""></div><div class="">Of course the big difference here with this idea compared to Apple’s internal API review process is that for Apple the APIs it vends are intended to be shipped together, and thus they must work together. In open source, however, efforts on various libraries are often (usually?) independent. Projects are usually created independently by different authors, and while it may be desirable for APIs from various libraries to feel natural to work with together, it’s not a requirement on their construction in general.</div></body></html>