deletions | additions       diff --git a/Rule 6. Publish your code.md b/Rule 6. Publish your code.md  index 74656a1..ae80d0a 100644  --- a/Rule 6. Publish your code.md  +++ b/Rule 6. Publish your code.md 
...
# Rule 6. Publish your code (even the small bits).  Did you write any code to run your analysis? **No matter how buggy and insignificant you may find it, publish it.** Many easy-to-use source code repositories exist, which allow not only hosting of software but also facilitate collaboration and version tracking (see Appendix D). Your code, even the shortest script (whether or not you are proud of its quality), can be an important component for understanding your data and how you got your results \cite{Barnes_2010}. Software plays several roles in relation to data and scientific research, and norms around its publication are still evolving and different across disciplines \cite{iroff_Mink_Hanisch_DuPrie_2013}. In some cases, software is the primary data product (e.g., new algorithms). In somecases, software is the primary data product (e.g., new algorithms). In some  other cases, data are the primary research products, yet the best way to document their provenance is to publish the software that was used to generate them as "metadata." In both cases, publishing the source code and its version history is crucial to enhance transparency and reproducibility. The use of open source software when possible reduces barriers for subsequent users of your software related data products. \cite{Prlic_Procter_2012} The same best practices discussed above in relation to data and workflow also apply to software materials: cite the software that you use and provide unique, persistent identifiers (Rule 2) to the code you share.