What follows is a curated transcription (minus noise/friendly banter) of topics discussed during my office hours in the F# Software Foundation slack:
cartermp [9:04 AM]
Hey folks, it’s time for some Phillip’s Office Hours
As a reminder, I’ll post a subset (no banter) of this chat log to the FSSF forums for further questions so that folks who weren’t here can ask questions
evgeny [9:09 AM]
@cartermp hello. what’s the main purpose of these meetings? I mean, do you have agenda?
cartermp [9:09 AM]
No agenda whatsoever (aside from world domination so that I can finally enforce my musical tastes on the rest of the world)
But people should certainly feel free to ask me questions about anything F#-related
evgeny [9:13 AM]
@cartermp I’d like to revive old question about roadmaps. would be nice to have one. not roadmap per se, but rather some plan “we’re working on this, some community folks are working on this (and they don’t mind getting help)”. no deadlines, just some info on what’s going on.
and no, “you can see it on github by using these tags” is not an answer. I’m talking about human-readable format
cartermp [9:18 AM]
I suppose I’ll ask a question back in response: roadmap about what? There are a few concurrent efforts that are ongoing (some are quite long-term), but it would help to understand what you’re looking for. Language/tools/infrastructure/etc.
Regarding community help, I can certainly pull together a few PRs, but that is ever-changing and we’ve intentionally kept from trying to control community work beyond technical concerns (i.e., “changing X in the typechecker is not a good approach, try Y instead”)
evgeny [9:19 AM]
I’ve intentionally omitted target, to generalize the question 
so, all of the above
tracy-gonzalez-rs [9:21 AM]
Would it make sense to start expanding FSharp.Core with incorporating some of the stuff in the various fsharp “core extension” libraries (like FSharpx, ExtCore, and FSharpPlus) ? For example, there’s a function called Async.sequence that I use pretty often that either requires including one of the FSharpx packages or writing it myself
cartermp [9:32 AM]
So, to answer your question, there are some high-level efforts we’re prioritizing at the moment:
• Moving our infrastructure to the .NET SDK so that we can properly support source builds, remove project.json, package correctly, and make our lives (and those of contributors not on Windows) generally easier
• Automated way to prevent Roslyn from breaking us again (completed)
• Refactoring our VS IDE bindings to Roslyn and the .NET project system, as we’re doing this in a fragile and inefficient way. Performance won’t help much, but stability and general “doing it right” is the goal there.
• Performance work remains a top ongoing priority for tooling. We currently don’t read .NET (non-F#) metadata as well as we could. There are known ways to make this consume far less memory than it does (likely using virtual memory), especially when there are long sessions of IDE use. We are also going to work with Roslyn to move F# out of process from the VS IDE, likely with a memory threshold of ~5GB before we start flushing caches. Should give people more “room”, so to speak.
• F# Interactive on .NET Core, with a pluggable mechanism called “compilertools” to support #r for packages, #r for projects, etc. is our highest priority for things that aren’t IDE-related.
• Stabilizing and flighting Anonymous Records for people to use via Nightlies before pulling into a future language branch.
• Work on Nullable Reference Types. The spec isn’t merged, but it’s pretty much to the point where it’s complete, and the targets aren’t moving as much as far as what the platform is doing, so we can do some serious work there without fear of having to rewrite.
• A task { } comprehension in the core library is a big deal for us fo F# 5.0 as well, which we’ll be implementing in some form between now and when it releases.
• “F# for machine learning” is an ongoing area of emphasis that Don has been working on, concretely with helping the ML.NET team better support F# record types. Things aren’t as well-known here, but a lot of work has already been put into relevant OSS libraries to make them work on .NET Core, clean up a few things, and seek out maintainers who are interested. We’ve gotten a new maintainer for Deedle, for example.
But the top priority for us all right now is stabilizing our existing VS state for the 15.9 release, which holds a high bar and is our “shut down and stabilize so it’s forever stable” release. Lots of larger organizations will be adopting VS 2017 for the first time over the next few years, so we need to make sure it’s stable and predictable as-is.
The issue with publicizing these sorts of things is that priorities change fast, and often, and so people can often get confused
evgeny [9:34 AM]
that’s why it should be updated ASAP
thank you very much, it’s a good status report 
cartermp [9:37 AM]
Additionally, there are efforts that are driven by internal goals (such as the VS 15.9 focus) - these often have a higher priority than community-driven goals, as we ultimately do deliver a product. These may not necessarily be something we can talk about (e.g., a security problem), but they take up time and affect what we do. That’s another wrinkle in publishing things anywhere, and it frustrates people.
What I’d ask is, what benefit is derived from an ever-changing set of priorities and things we’re working on? It’s not entirely clear to me what people get out of that, especially given the nature of our work not being as linear as people would think.
evgeny [9:41 AM]
I believe it would lower barriers to enter development
cartermp [9:43 AM]
@evgeny Just to clarify, is the idea that knowing what we’re working on (beyond what’s an open PR) makes it easier for OSS contributors to focus their efforts?
evgeny [9:44 AM]
@cartermp yes. also it makes it easier to jump in if somebody notices that there is work around some feature, which is critical for them
cartermp [9:44 AM]
@tracy-gonzalez-rs Re this:
Would it make sense to start expanding FSharp.Core with incorporating some of the stuff in the various fsharp “core extension” libraries (like FSharpx, ExtCore, and FSharpPlus) ?
I personally think it could be helpful, but it’s not clear to me which pieces of those libraries people use the most, and if any are pervasive. I think that the AsyncSeqtype would make sense for F# to deliver in conjunction with C# 8.0, since C# is doing a kind of async sequence as well. But I’m also not sure what drives the use of AsyncSeq for F# developers today, and I wouldn’t want to shove it in there just because it makes sense from a timing standpoint.
tracy-gonzalez-rs [9:49 AM]
Sorry. I was referring to the “sequential” analog to the Async.Parallel function, not the AsyncSeq library. Your point is noted, however. (edited)
tracy-gonzalez-rs [9:53 AM]
Def not clear, but still, having to choose between core “extension” libraries and/or duplicating boilerplate library code has been an issue for me and I suspect other people as well
It’s sort of feels like the same problem node.js has (albeit not as severe) due to a lack of a javascript standard library (edited)
Perhaps the solution is to submit uservoice suggestions for functions to add to FSharp.Core and proceed piecemeal this way
cartermp [9:56 AM]
One thing I will say is that if the functions/types are simple and/or have an easy implementation, that helps things tremendously
This is why things like Array.transpose were added to the library - such a function is easy to write and test adequately
tracy-gonzalez-rs [9:57 AM]
Yeah, generally the ones I’m thinking of are. Eg. Choice.mapSnd. (edited)
cartermp [9:57 AM]
Although this one still needs Don Approval, I see this as an example of something worth adding: Add Async.withCancellation · Issue #685 · fsharp/fslang-suggestions · GitHub