The F# Core Engineering Group: Goals and Remit
This document describes the goals, remit and activities of the F# Core Engineering Group.
To organise, promote and contribute to work on F#’s core tooling to make development pain free and fully featured, enable it on new platforms, host F# code in new ways and ensure best-practice engineering in the F# community.
The group’s remit covers the following areas:
Language Design Process
We run the F# Language and Core Library Design Process. This includes F# Language Design GitHub.
Compiler, Core Library and Compiler Service
The group commits to ensuring the easy availability of the F# Compiler, Core library and Compiler Service on all major platforms at high quality. Particular points of activity are:
We work cooperatively with the Visual F# compiler team at Microsoft to allow open source contributions and integrate Microsoft updates to the F# open source release into the F# repositories on GitHub.
(See this blog entry and the Visual F# Team priorities)
We work cooperatively with Xamarin to integrate the F# Compiler into Mono releases on the Mac and Linux
We enable testing for the open edition of the F# compiler, particularly through CI systems (Travis and AppVeyor)
We work cooperatively with Debian packaging and other distributions to ensure Linux packages are available for F# on Debian and RPM, Gentoo/Arch builds
We work cooperatively with the Visual F# compiler team to align code bases with Visual F# team repos
We aim to keep the the homebrew formula for F# up-to-date
We help maintain and improve the PCL (Portable Class Library) and .NET Standard support for F# across multiple platforms and devices
We aim to improve the documentation quality of the core compiler and library components.
We aim to help facilitate cross-platform development on the compiler, core library and compiler service.
The group aims to help the F# community deliver high quality, consistent, easy-to-install, reliable editing experiences for F# code on all major platforms and as many editors as feasible. We also aim to encourage and facilitate Notebook/Workbook experiences (e.g. iPython notebook)
The group aim to contribute to improving package management and tools that support cross-platform F# development.
Virtual Machine Images/Containers
The group encourages and facilitates the creation of pre-bundled VM images and containers which include F#, e.g.
Docker (e.g. The Official Docker F# Image
Vagrant (e.g. this image
The group aim to
Improve CI support for F# in common CI systems such as Travis, AppVeyor
Share knowledge and best practice for CI systems, encourage use of CI
Use CI for core F# community projects
Libraries and Frameworks
The group aims to
Facilitate an active, high-quality ecosystem of F# libraries.
Maintain and improve the F# Component Design Guidelines
We especially focus on libraries using the FSharp.* namespace. This includes
Contributing to libraries and frameworks
Assessing the quality of libraries and frameworks
Reviewing library and framework designs
Working with projects like FSharpx and ExtCore to create a cohesive set of libraries and packages
Starting new library projects
Proactively deprecating existing libraries
We focus on tooling to support the generation of libraries by the F# community
PCL (portable class libraries) on all platforms
We will consider having the FSSF “blessed” libraries and tools through one or more of:
Publishing them under a FSSF NuGet accounts
Documenting them under fsharp.org
Blessing them as “supported”, where they are considered a very official and stable part of the F# library base
The criteria for a library or framework to get this blessing will be rigorous - for example it must be uniquely significant F# functionality, not be experimental and must be stable and tested. It should also be cross-platform, where possible.
We will look for inspiration from other package-based software communities for how to manage this process.
We will loko to improve existing Type Providers and ensure they work cross platform.
The group aims to facilitate the development of new F# development experiences through “hosting” F# (whether client-side as an API, server-side or other variations).
The group commits to
maintaining and regularly validating the “getting started” guides already available on fsharp.org
creating and maintaining development guides for all major platforms on fsharp.org
Make tools that generate top-quality documentation (e.g. FSharp.Formatting) and help disseminate these to the F# community.
Better documentation for all of the impressive work that has already been done
Help the community create roadmaps for core libraries to improve functionality, engineering, and documentation
The group aims to facilitate and encourage core interoperability tooling such as
Type providers to other programming languages (Java etc.)
Knowledge of tooling that can be used to interoperate with other systems
Distributed Computing Frameworks
While not part of the core remit of the group, we keep an eye on and encourage/facilitate the emerging distributed compute frameworks which work well with F# code, for example, Akka.NET, M-Brace/Cloud-F# and Orleans.
What We Don’t Do
We don’t maintain every library and tool that the F# community creates. Only the following components are “maintained” by this group.
All other projects are done on a cooperative basis with the project owners and F# community.
We don’t duplicate functionality available in the F# exosystem (.NET, C#, NuGet etc.)
We don’t focus on tools/libraries clearly in the remit of another working group, e.g. math libraries. We will, however, work with these groups to help make sure their libraries and tools fit into a cohesive and simple overall picture for F#.
We don’t allow junk libraries and tools to “hang around” if they are dead projects or low quality.
We don’t focus on tooling that relies on other minority 3rd party proprietary editors. (Xamarin is OK because it also works in MonoDevelop, Resharper is not, partly because the API is complex. Visual Studio tooling is OK because it is so massive in the F# ecosystem)
Larger projects such as improved mobile support will probably need to end up as separate discussions with teams of volunteers. Most of these are mentioned in ‘Initial Remit’ above.
Published: 02 July 2013
Updated: 19 September 2014
Updated: 27 September 2016
(on behalf of the F# Core Engineering group)