unix2dos

Author: penelopeysm

developers/compiler/design-overview/index.qmd

@@ -1,78 +1,78 @@
----
-title: Contributing
-aliases:
-  - ../../tutorials/docs-01-contributing-guide/index.html
----
-
-Turing is an open-source project and is [hosted on GitHub](https://github.com/TuringLang).
-We welcome contributions from the community in all forms large or small: bug reports, feature implementations, code contributions, or improvements to documentation or infrastructure are all extremely valuable.
-We would also very much appreciate examples of models written using Turing.
-
-### How to get involved
-
-Our outstanding issues are tabulated on our [issue tracker](https://github.com/TuringLang/Turing.jl/issues).
-Closing one of these may involve implementing new features, fixing bugs, or writing example models.
-
-You can also join the `#turing` channel on the [Julia Slack](https://julialang.org/slack/) and say hello!
-
-If you are new to open-source software, please see [GitHub's introduction](https://guides.github.com/introduction/flow/) or [Julia's contribution guide](https://github.com/JuliaLang/julia/blob/master/CONTRIBUTING.md) on using version control for collaboration.
-
-### Documentation
-
-Each of the packages in the Turing ecosystem (see [Libraries](/library)) has its own documentation, which is typically found in the `docs` folder of the corresponding package.
-For example, the source code for DynamicPPL's documentation can be found in [its repository](https://github.com/TuringLang/DynamicPPL.jl).
-
-The documentation for Turing.jl itself consists of the tutorials that you see on this website, and is built from the separate [`docs` repository](https://github.com/TuringLang/docs).
-None of the documentation is generated from the [main Turing.jl repository](https://github.com/TuringLang/Turing.jl); in particular, the API that Turing exports does not currently form part of the documentation.
-
-Other sections of the website (anything that isn't a package, or a tutorial) – for example, the list of libraries – is built from the [`turinglang.github.io` repository](https://github.com/TuringLang/turinglang.github.io).
-
-### Tests
-
-Turing, like most software libraries, has a test suite. You can run the whole suite by running `julia --project=.` from the root of the Turing repository, and then running
-
-```julia
-import Pkg; Pkg.test("Turing")
-```
-
-The test suite subdivides into files in the `test` folder, and you can run only some of them using commands like
-
-```julia
-import Pkg; Pkg.test("Turing"; test_args=["optim", "hmc", "--skip", "ext"])
-```
-
-This one would run all files with "optim" or "hmc" in their path, such as `test/optimisation/Optimisation.jl`, but not files with "ext" in their path. Alternatively, you can set these arguments as command line arguments when you run Julia
-
-```julia
-julia --project=. -e 'import Pkg; Pkg.test(; test_args=ARGS)' -- optim hmc --skip ext
-```
-
-Or otherwise, set the global `ARGS` variable, and call `include("test/runtests.jl")`. 
-
-### Style Guide
-
-Turing has a style guide, described below.
-Reviewing it before making a pull request is not strictly necessary, but you may be asked to change portions of your code to conform with the style guide before it is merged.
-
-Most Turing code follows [Blue: a Style Guide for Julia](https://github.com/JuliaDiff/BlueStyle).
-These conventions were created from a variety of sources including Python's [PEP8](http://legacy.python.org/dev/peps/pep-0008/), Julia's [Notes for Contributors](https://github.com/JuliaLang/julia/blob/master/CONTRIBUTING.md), and Julia's [Style Guide](https://docs.julialang.org/en/v1/manual/style-guide/).
-
-#### Synopsis
-
-  - Use 4 spaces per indentation level, no tabs.
-  - Try to adhere to a 92 character line length limit.
-  - Use upper camel case convention for [modules](https://docs.julialang.org/en/v1/manual/modules/) and [types](https://docs.julialang.org/en/v1/manual/types/).
-  - Use lower case with underscores for method names (note: Julia code likes to use lower case without underscores).
-  - Comments are good, try to explain the intentions of the code.
-  - Use whitespace to make the code more readable.
-  - No whitespace at the end of a line (trailing whitespace).
-  - Avoid padding brackets with spaces. ex. `Int64(value)` preferred over `Int64( value )`.
-
-#### A Word on Consistency
-
-When adhering to the Blue style, it's important to realize that these are guidelines, not rules. This is [stated best in the PEP8](http://legacy.python.org/dev/peps/pep-0008/#a-foolish-consistency-is-the-hobgoblin-of-little-minds):
-
-> A style guide is about consistency. Consistency with this style guide is important. Consistency within a project is more important. Consistency within one module or function is most important.
-
-> But most importantly: know when to be inconsistent – sometimes the style guide just doesn't apply. When in doubt, use your best judgment. Look at other examples and decide what looks best. And don't hesitate to ask!
-
+---
+title: Contributing
+aliases:
+  - ../../tutorials/docs-01-contributing-guide/index.html
+---
+
+Turing is an open-source project and is [hosted on GitHub](https://github.com/TuringLang).
+We welcome contributions from the community in all forms large or small: bug reports, feature implementations, code contributions, or improvements to documentation or infrastructure are all extremely valuable.
+We would also very much appreciate examples of models written using Turing.
+
+### How to get involved
+
+Our outstanding issues are tabulated on our [issue tracker](https://github.com/TuringLang/Turing.jl/issues).
+Closing one of these may involve implementing new features, fixing bugs, or writing example models.
+
+You can also join the `#turing` channel on the [Julia Slack](https://julialang.org/slack/) and say hello!
+
+If you are new to open-source software, please see [GitHub's introduction](https://guides.github.com/introduction/flow/) or [Julia's contribution guide](https://github.com/JuliaLang/julia/blob/master/CONTRIBUTING.md) on using version control for collaboration.
+
+### Documentation
+
+Each of the packages in the Turing ecosystem (see [Libraries](/library)) has its own documentation, which is typically found in the `docs` folder of the corresponding package.
+For example, the source code for DynamicPPL's documentation can be found in [its repository](https://github.com/TuringLang/DynamicPPL.jl).
+
+The documentation for Turing.jl itself consists of the tutorials that you see on this website, and is built from the separate [`docs` repository](https://github.com/TuringLang/docs).
+None of the documentation is generated from the [main Turing.jl repository](https://github.com/TuringLang/Turing.jl); in particular, the API that Turing exports does not currently form part of the documentation.
+
+Other sections of the website (anything that isn't a package, or a tutorial) – for example, the list of libraries – is built from the [`turinglang.github.io` repository](https://github.com/TuringLang/turinglang.github.io).
+
+### Tests
+
+Turing, like most software libraries, has a test suite. You can run the whole suite by running `julia --project=.` from the root of the Turing repository, and then running
+
+```julia
+import Pkg; Pkg.test("Turing")
+```
+
+The test suite subdivides into files in the `test` folder, and you can run only some of them using commands like
+
+```julia
+import Pkg; Pkg.test("Turing"; test_args=["optim", "hmc", "--skip", "ext"])
+```
+
+This one would run all files with "optim" or "hmc" in their path, such as `test/optimisation/Optimisation.jl`, but not files with "ext" in their path. Alternatively, you can set these arguments as command line arguments when you run Julia
+
+```julia
+julia --project=. -e 'import Pkg; Pkg.test(; test_args=ARGS)' -- optim hmc --skip ext
+```
+
+Or otherwise, set the global `ARGS` variable, and call `include("test/runtests.jl")`. 
+
+### Style Guide
+
+Turing has a style guide, described below.
+Reviewing it before making a pull request is not strictly necessary, but you may be asked to change portions of your code to conform with the style guide before it is merged.
+
+Most Turing code follows [Blue: a Style Guide for Julia](https://github.com/JuliaDiff/BlueStyle).
+These conventions were created from a variety of sources including Python's [PEP8](http://legacy.python.org/dev/peps/pep-0008/), Julia's [Notes for Contributors](https://github.com/JuliaLang/julia/blob/master/CONTRIBUTING.md), and Julia's [Style Guide](https://docs.julialang.org/en/v1/manual/style-guide/).
+
+#### Synopsis
+
+  - Use 4 spaces per indentation level, no tabs.
+  - Try to adhere to a 92 character line length limit.
+  - Use upper camel case convention for [modules](https://docs.julialang.org/en/v1/manual/modules/) and [types](https://docs.julialang.org/en/v1/manual/types/).
+  - Use lower case with underscores for method names (note: Julia code likes to use lower case without underscores).
+  - Comments are good, try to explain the intentions of the code.
+  - Use whitespace to make the code more readable.
+  - No whitespace at the end of a line (trailing whitespace).
+  - Avoid padding brackets with spaces. ex. `Int64(value)` preferred over `Int64( value )`.
+
+#### A Word on Consistency
+
+When adhering to the Blue style, it's important to realize that these are guidelines, not rules. This is [stated best in the PEP8](http://legacy.python.org/dev/peps/pep-0008/#a-foolish-consistency-is-the-hobgoblin-of-little-minds):
+
+> A style guide is about consistency. Consistency with this style guide is important. Consistency within a project is more important. Consistency within one module or function is most important.
+
+> But most importantly: know when to be inconsistent – sometimes the style guide just doesn't apply. When in doubt, use your best judgment. Look at other examples and decide what looks best. And don't hesitate to ask!
+