All contributions made to this project are subject to terms and conditions of the Apache License, Version 2.0. A copy of the license can be found in the
License.html file at the root of this distribution. By using this source code in any fashion, you are agreeing to be bound by the terms of the Apache License, Version 2.0. You
must not remove this notice, or any other, from this software. If you have requirements for a different license raise it in the discussion forum, we will work with you and our legal representatives to work out a mutually satisfactory solution.
Types of Contributions
Early Feedback and Suggestions
Providing feedback and suggestions on in-development features is a great way for you to get the feel of F# development and for you to contribute concrete improvements to the product. Download a recent daily build from our drop site, install
it on a development machine, and begin partying on the features that are in development and appeal to you.
Give your feedback in the
discussion forum, or raise an issue on the
issues page. Even better, grab the
source code, write a fix with tests, and issue a pull request.
One of the most valuable ways to contribute is to fix or file bugs. Visit the issues page to add a new bug, provide a comment on an existing bug, or to find bugs that need fixing.
If you have developed a fix for a bug and added regression tests to validate the change, issue a pull request. The Visual F# team, along with the community, will review and potentially integrate the fix.
Another way to contribute is to add, clarify, or clean up comments in the codebase. If you feel that a section of the codebase is particularly confusing and could benefit from improved comments/documentation, write it up and issue a pull request.
If there are particular features that you rely on extensively, take a look at our current set of test assets for those features. If you see test coverage gaps that you believe are valuable to fill in, author the missing cases and issue a pull request.
Feature contributions via pull request are welcome, but note that any such contribution will need to meet a high bar to be considered. For any potential new feature, the quality of the overall design, technical implementation, and added test coverage
will be closely examined. An otherwise excellent feature contribution might still be rejected if the feature does fit into the planned product roadmap. It also might be more appropriate for new features or libraries to exist as independent projects,
rather than integrated directly into the core toolset.
Considering all of the above, it is strongly recommended that you propose and discuss any new features or significant changes on the discussions page
before investing significant time on them. This gives the Visual F# team and the rest of the F# community an opportunity to provide feedback and ideas on how best to approach the change, and to discuss whether such a change is appropriate.
As with any other contribution, all feature contributions must be submitted with a high quality regression test suite. Code for both product and tests will be reviewed and validated by the F# community and the Visual F# team, and feedback
will be provided via CodePlex.
Review and integration of larger features will usually be restricted to the first few weeks of the quarterly release cycle, to allow for bake time and stabilization.
You will need to sign a
Contribution License Agreement before a pull request will be considered. To complete the Contribution License Agreement (CLA), you will need to submit a request via the form and then electronically sign the Contributor License Agreement when you receive
the email containing the link to the document. This only needs to be done once for each Microsoft Open Technologies OSS project you contribute to.
create a fork and implement your changes there. When your changes are complete, issue a pull request back to the primary repo. You may be asked to iterate
and make changes before your request is accepted.
Contributions will only be accepted which can be easily merged onto the tip of the existing CodePlex sources. Please handle any merge conflicts before submitting a pull request.
Before submitting a pull request, ensure all projects build successfully and all tests are passing. Refer to the
how to build,
how to run tests, and required software pages for help with this.
Commit messages should clearly describe all changes included, and provide context on the intent of the change. While not every commit requires a multiple-sentences-long comment, all comments should be well-written and grammatically correct.
If a commit resolves or relates to a known bug, CodePlex supports automatically linking to that issue by including
#<issue number> in your comment. e.g.
Fix for compiler issue #4242
Although there is currently no strict set of coding or style guidelines, use common sense when contributing code - make an effort to use a similar style to nearby existing code. If you have a passion for helping us develop a set of coding
guidelines that we can roll out and apply within this project, get involved and start a thread on the