Skip to content
Permalink
Browse files

style: run markdown through markdown linter

  • Loading branch information...
mhamilton723 committed Jul 31, 2019
1 parent a0e85f5 commit 07c7fecf78af53d56f66565dd9b5033019eb71b1
Showing with 732 additions and 763 deletions.
  1. +5 −1 .gitignore
  2. +50 −50 CONTRIBUTING.md
  3. +116 −121 README.md
  4. +68 −68 docs/R-setup.md
  5. +83 −80 docs/SAR.md
  6. +9 −9 docs/datasets.md
  7. +9 −9 docs/developer-readme.md
  8. +113 −121 docs/docker.md
  9. +102 −106 docs/http.md
  10. +33 −35 docs/lightgbm.md
  11. +91 −97 docs/mmlspark-serving.md
  12. +10 −17 docs/vagrant.md
  13. +43 −49 docs/your-first-model.md
@@ -39,4 +39,8 @@
# python test coverage
.coverage
coverage.xml
htmlcov
htmlcov

# Files created by remark-link
package-lock.json
node_modules/
@@ -2,12 +2,12 @@

### You can contribute in many ways:

* Use the library and give feedback: report bugs, request features.
* Add sample Jupyter notebooks, Python or Scala code examples, documentation
pages.
* Fix bugs and issues.
* Add new features, such as data transformations or machine learning algorithms.
* Review pull requests from other contributors.
- Use the library and give feedback: report bugs, request features.
- Add sample Jupyter notebooks, Python or Scala code examples, documentation
pages.
- Fix bugs and issues.
- Add new features, such as data transformations or machine learning algorithms.
- Review pull requests from other contributors.

### How to contribute?

@@ -19,65 +19,65 @@ this process:

#### Propose a contribution

* Preferably, get started by tackling existing issues to get yourself acquainted
with the library source and the process.
* Open an issue, or comment on an existing issue to discuss your contribution
and design, to ensure your contribution is a good fit and doesn't duplicate
on-going work.
* Any algorithm you're planning to contribute should be well known and accepted
for production use, and backed by research papers.
* Algorithms should be highly scalable and suitable for very large datasets.
* All contributions need to comply with the MIT License. Contributors external
to Microsoft need to sign CLA.
- Preferably, get started by tackling existing issues to get yourself acquainted
with the library source and the process.
- Open an issue, or comment on an existing issue to discuss your contribution
and design, to ensure your contribution is a good fit and doesn't duplicate
on-going work.
- Any algorithm you're planning to contribute should be well known and accepted
for production use, and backed by research papers.
- Algorithms should be highly scalable and suitable for very large datasets.
- All contributions need to comply with the MIT License. Contributors external
to Microsoft need to sign CLA.

#### Implement your contribution

* Fork the MMLSpark repository.
* Implement your algorithm in Scala, using our wrapper generation mechanism to
produce PySpark bindings.
* Use SparkML `PipelineStage`s so your algorithm can be used as a part of
pipeline.
* For parameters use `MMLParam`s.
* Implement model saving and loading by extending SparkML `MLReadable`.
* Use good Scala style.
* Binary dependencies should be on Maven Central.
* See this [pull request](https://github.com/Azure/mmlspark/pull/22) for an
example contribution.
- Fork the MMLSpark repository.
- Implement your algorithm in Scala, using our wrapper generation mechanism to
produce PySpark bindings.
- Use SparkML `PipelineStage`s so your algorithm can be used as a part of
pipeline.
- For parameters use `MMLParam`s.
- Implement model saving and loading by extending SparkML `MLReadable`.
- Use good Scala style.
- Binary dependencies should be on Maven Central.
- See this [pull request](https://github.com/Azure/mmlspark/pull/22) for an
example contribution.

#### Implement tests

* Set up build environment. Use a Linux machine or VM (we use Ubuntu, but other
distros should work too), and install environment using the [`runme`
script](runme).
* Test your code locally.
* Add tests using ScalaTests — unit tests are required.
* A sample notebook is required as an end-to-end test.
- Set up build environment. Use a Linux machine or VM (we use Ubuntu, but other
distros should work too), and install environment using the [`runme`
script](runme).
- Test your code locally.
- Add tests using ScalaTests — unit tests are required.
- A sample notebook is required as an end-to-end test.

#### Implement documentation

* Add a [sample Jupyter notebook](notebooks/samples) that shows the intended use
case of your algorithm, with instructions in step-by-step manner. (The same
notebook could be used for testing the code.)
* Add in-line ScalaDoc comments to your source code, to generate the [API
reference documentation](https://mmlspark.azureedge.net/docs/pyspark/)
- Add a [sample Jupyter notebook](notebooks/samples) that shows the intended use
case of your algorithm, with instructions in step-by-step manner. (The same
notebook could be used for testing the code.)
- Add in-line ScalaDoc comments to your source code, to generate the [API
reference documentation](https://mmlspark.azureedge.net/docs/pyspark/)

#### Open a pull request

* In most cases, you should squash your commits into one.
* Open a pull request, and link it to the discussion issue you created earlier.
* An MMLSpark core team member will trigger a build to test your changes.
* Fix any build failures. (The pull request will have comments from the build
with useful links.)
* Wait for code reviews from core team members and others.
* Fix issues found in code review and re-iterate.
- In most cases, you should squash your commits into one.
- Open a pull request, and link it to the discussion issue you created earlier.
- An MMLSpark core team member will trigger a build to test your changes.
- Fix any build failures. (The pull request will have comments from the build
with useful links.)
- Wait for code reviews from core team members and others.
- Fix issues found in code review and re-iterate.

#### Build and check-in

* Wait for a core team member to merge your code in.
* Your feature will be available through a Docker image and script installation
in the next release, which typically happens around once a month. You can try
out your features sooner by using build artifacts for the version that has
your changes merged in (such versions end with a `.devN`).
- Wait for a core team member to merge your code in.
- Your feature will be available through a Docker image and script installation
in the next release, which typically happens around once a month. You can try
out your features sooner by using build artifacts for the version that has
your changes merged in (such versions end with a `.devN`).

If in doubt about how to do something, see how it was done in existing code or
pull requests, and don't hesitate to ask.

0 comments on commit 07c7fec

Please sign in to comment.
You can’t perform that action at this time.