Hello Ted, would you mind opening a new thread and post an update about the forum and maybe answer a few minor questions like: - what is currently planned? - in which timeframe we *might* see the forum finally happening (don’t have to be a promise)? - what happens to old mailing lists? (I’d say put a public archive somewhere, maybe slightly better formatted than the mailing list is, but do not spam new categories so that we can start with a fresh and clean forum. I also wouldn’t bother with migrating old users to new accounts. If I’m interested in contribution I can take a minute and create a new forum account. I mean we’re not trying to sell here anything, so this shouldn’t be a high priority right!?)
Thank you. :) Am 9. November 2017 um 07:12:10, Ted Kremenek via swift-evolution ([email protected]) schrieb: On Nov 8, 2017, at 12:08 PM, Kelvin Ma <[email protected]> wrote: On Wed, Nov 8, 2017 at 1:58 PM, Ted Kremenek via swift-evolution <[email protected]> wrote: On Nov 8, 2017, at 11:40 AM, Ted Kremenek via swift-evolution <[email protected]> wrote: On Nov 8, 2017, at 4:30 AM, Wallacy via swift-evolution <[email protected]> wrote: 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. I’m a bit confused. I’m not sure what comments of mine I’m referring to. Clearly I’m double confused. That meant to read “I’m not sure what comments of mine *you* are referring to”. 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. 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. These are great points. 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.? 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. 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. 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. _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
