> On Nov 8, 2017, at 12:08 PM, Kelvin Ma <kelvin1...@gmail.com> wrote:
>
>
>
> On Wed, Nov 8, 2017 at 1:58 PM, Ted Kremenek via swift-evolution
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
>
>> On Nov 8, 2017, at 11:40 AM, Ted Kremenek via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>>
>>
>>> On Nov 8, 2017, at 4:30 AM, Wallacy via swift-evolution
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
