* Reuse intro from contributing.rst
* Removed content already on rst
Simplified CONTRIBUTING.md by removing content that already
exists in contributing.rst. Added Code of Conduct reference
as seen in a few other CONTRIBUTING.md of popular libraries.
* Update contributing.rst
In shortening `CONTRIBUTING.md`, material deleted from `how to contribute` section are added onto `contributing.rst` if it doens't exist on the latter.
* added full link to .rst file + removed 'Full' in 'Full Docum...'
<!--
Thanks for contributing a pull request! Please ensure you have taken a look at
the contribution guidelines: https://github.com/scikit-learn/scikit-learn/blob/master/CONTRIBUTING.md#pull-request-checklist
-->
#### Reference Issues/PRs
<!--
Example: Fixes#1234. See also #3456.
Please use keywords (e.g., Fixes) to create link to the issues or pull requests
you resolved, so that they will automatically be closed when your pull request
is merged. See https://github.com/blog/1506-closing-issues-via-pull-requests
-->
#### What does this implement/fix? Explain your changes.
As far as I understand it, the fact that `fit` is idempotent means that repeated calls to `fit` with the same data doesn't change the estimator.
The contributing guide was a bit unclear about this.
#### Any other comments?
<!--
Please be aware that we are a loose team of volunteers so patience is
necessary; assistance handling other issues is very welcome. We value
all user contributions, no matter how minor they are. If we are slow to
review, either the pull request needs some benchmarking, tinkering,
convincing, etc. or more likely the reviewers are simply busy. In either
case, we ask for your understanding during the review process.
For more information, see our FAQ on this topic:
http://scikit-learn.org/dev/faq.html#why-is-my-pull-request-not-getting-any-attention.
Thanks for contributing!
-->
Skeleton for a glossary of concepts and API elements.
This responds to at least three issues:
* Many aspects of scikit-learn API for users and developers are known
tacitly by core contributors (and the stack overflow crowd), but are
not written down in a consistent place.
* What is written is in an ad-hoc narrative style which may be useful
for introduction, but is difficult to refer to and to maintain.
* Parameters such as `n_jobs` and methods like `decision_function` are
described repeatedly in documentation giving sometimes more sometimes
less information. This glossary allows us to use "See :term:`the
glossary <n_jobs>`." so that parameter descriptions in the
API reference can remain brief (just as not every numpy operation
needs to describe broadcasting).
Thomas Fan
Hanmin Qin