This project is read-only.

A procedure for contributing to Visual F# Tools' addin

Jul 6, 2014 at 7:48 PM
Edited Jul 6, 2014 at 7:48 PM
About the language and core libraries part, it's totally transparent on what are approved in principle ( and what are being done (

What is the procedure for contributing to the VS addin part? Suppose I have a feature request I would like to contribute, what process should I follow e.g.
  1. Open an issue on, wait for it to be approved (I haven't seen any approved feature request) and send a pull request.
  2. Open an issue on Codeplex, get approval from the coordinators and send a pull request.
  3. Something else?
I'm sorry if I miss this information somewhere.
Jul 7, 2014 at 4:57 AM
Make a proposal on user-voice, tweet that you have done so, since I don't look there much. Send a PR when you are ready. I would rather you didn't wait for 'approval'. it's your idea after all, its just that be aware if its one we believe weakens the product then we are unlikely to take it. However, since you folks actually use the product daily you are unlikely to break it, so I wouldn't worry too much. Use your judgment, and it will all work out fine I expect. We want to enable you guys to make the product you want to use, so propose it, discuss it, do it, submit it.

Kevin Ransom
Jul 7, 2014 at 9:49 PM

It seems there is too much freedom in contributing to Visual F# Tools' addin. Normally a feature needs extensive discussion before the scope is well-defined for implementation. I'm not sure people will be active on User Voice to discuss feature requests when F# team doesn't really monitor it. An issue on codeplex will get much more visibility and it's more likely to be discussed.

Anyway, I know what is an appropriate way to go forward now.
Jul 7, 2014 at 11:15 PM
I think you misunderstand me. Our goal is to allow us to build the tool we all want to build ... together. It is not our intent to stop anyone from trying out whatever feature she wants to implement. Ideally you will discuss the feature with other members of the community, it will certainly be code reviewed, tried out and tested before a PR is accepted. If the consensus of the team and community is that the feature is a good one and well implemented then it will likely be accepted. If not then it won't.

However, if you seek my permission to add a feature then you will constrain the product to only have what I think is good, I'm not sure that that is a good model, I'm pretty certain I don't want that responsibility. The best way to proceed is to discuss your proposed feature, on uservoice or CodePlex, create a prototype and let us all kick the tyres and see if we like it.
Jul 7, 2014 at 11:21 PM
Indeed. I've got it now. Thanks.
Jul 7, 2014 at 11:41 PM
Opening a discussion (like this one) on Codeplex to discuss any significant new features should definitely be done before embarking on a bunch of work. We don't want any individuals or teams to work hard on a big contribution only to learn at the very end that it won't be accepted (maybe because it doesn't fit with other team goals, because something similar is already in progress, etc etc).

Discussing in the open beforehand has a number of other benefits
  • You can discuss and refine the design/scope of new features with VF# team + community
  • You can recruit people to help work on it
  • You can get advice on where the feature would integrate best
  • You can get advice on how to integrate testing, and where we might be able to assist with internal VS IDE test tools.