Topic: Which APIs belong into CoreFX vs. not (7 votes)

[karelz]

Talking points:

• See #20902 (CoreFxExtensions repo) for current list
• We consider only 'core' types to be part of CoreFX. Incl. types which we need to use ourselves.
  • Advanced types and data structures should be ideally outside of CoreFX.
  • Quite a few CoreFX types today should be ideally outside (e.g. DirectoryServices, ImmutableCollections, etc.)
    • We may one day try to move them out.
    • Right now we use the rule "if it is in .NET Standard" or "if it shipped in .NET Framework", let's not take overhead of yet another repo to maintain and monitor (incl. infra).
• Why people often want APIs in CoreFX?
  • Key reason: Microsoft takes care of them from now on.
    • That does not scale. We can't become experts on everything. We won't grow the team infinitely. The more we own, the less time we have to focus on areas and innovate them.
• Why not CoreFxLab?
  • CoreFxLab is meant for fast iterations and experiments. Code review process is very lightweigth (incl. 2 hours no reponse from anyone = I can checkin).
  • We plan to scale back CoreFxLab to projets which have Microsoft employee sponsor
    • Key value: Avoid 1 year opened PRs on Command line parser, where we did not want to invest anymore.
    • Community members would be free to take the source code and continue with it in their / community repos (e.g. take it into CoreFxExtensions).
• Idea: CoreFxExtensions repo? #20902
  • Pro: Easier way to build community around new 'advanced' APIs (PowerCollections, Graphs, Heaps, etc.), pre-setup NuGet publishing & CI system
    • Key value: Remove the initial non-trivial investment to build your own library (CI, NuGet publishing).
    • Key value: Simplify growing community around the library (people to help with advice and PRs).
  • Question: Driven by Microsoft (slow moving due to limited investment) vs. community (not System/Microsoft namespace) with .NET team guidance (e.g. API reviews help, etc.)
    • Idea: Community could have (proven) champions/experts/owners for specific areas (e.g. PowerCollections), who could shepherd the area and play the role of area owner/expert same way as we do in CoreFX repo.
  • Question: What to do with areas where champions/experts/owners disappear?
    • Delete them the same way we plan to do it in CoreFxLab?
    • Communicate that the area/library is on life support (only must-have fixes) and waits for someone to prove they can move it forward?
• Example of controversial API: PriorityQueue requires first experiments in CoreFxLab #574, before we can decide on API shape (the implementation feeds back into design)
• Question: How to deal with APIs that are off-topic, we don't think are good idea? Close more aggressively?
  • Idea: We probably need a blog post / documentation we can point people to with reasons why we do not take certain class of APIs (incl. reasons listed here - like "avoiding Microsoft will take care of it from now").

[shmuelie]

I think there are two "needs" behind a CoreFxExtensions repo

1. APIs that are commonly used, but not "core enough" to want in the core. ASP.NET, JSON.net, etc are used by tons of people and are thought of as part of .NET but aren't core or "needed" to make simpler programs. On the other hand they are used by so many and in so many critical applications that having one, "good" way to do to is needed.
2. API experimentation with larger group than CoreFxLab and more measured.

I think an idea might be to take a lead from ASP.NET and do Microsoft.Extensions for this (and yes, that means driven by Microsoft)

[karelz]

ASP.NET and proven community projects (like JSON.net) do not need any new repo. They have great home, healthy community and all is great :)

CoreFxLab is the right place for experiments which may (or may not) end up in CoreFX repo and friends. That is its primary purpose. We do not plan to ship any packages out of CoreFxLab, it is the experimental staging zone.

CoreFxExtensions can go 2 ways -- either with Microsoft namespace, which means only a few things will make it in (we have only limited capacity after all), or with Community namespace, which means it can be wider as CoreFX team's capacity won't be the bottleneck (we will provide just guidance / direction when needed). Does it make sense?

This is just proposal and options, nothing is set to stone. Anything can be changed. Just trying to communicate the limitations / reasoning for decisions & direction.

[shmuelie]

ASP.NET and proven community projects (like JSON.net) do not need any new repo. They have great home, healthy community and all is great :)

Didn't mean that they should be moved. Just using them as examples of libraries the "dark matter developer" might think of as core to .NET (and is in a sense) but doesn't belong in CoreFx

CoreFxLab is the right place for experiments which may (or may not) end up in CoreFX repo and friends. That is its primary purpose. We do not plan to ship any packages out of CoreFxLab, it is the experimental staging zone.

Agreed.

CoreFxExtensions can go 2 ways -- either with Microsoft namespace, which means only a few things will make it in (we have only limited capacity after all), or with Community namespace, which means it can be wider as CoreFX team's capacity won't be the bottleneck (we will provide just guidance / direction when needed). Does it make sense?

I think we need a bit of both. If it's just community driven then the community can do it themselves as they have for years. Just Microsoft and it's not a big enough difference from CoreFx to be a different repo. We need a balance of the two that gives the capacity of the community, the reach of Microsoft's knowledge of the customer base, etc. Obviously it won't be perfect but if we can find that sweet spot...