{"action":"created","issue":{"url":"https://api.github.com/repos/mozillascience/studyGroupLessons/issues/7","labels_url":"https://api.github.com/repos/mozillascience/studyGroupLessons/issues/7/labels{/name}","comments_url":"https://api.github.com/repos/mozillascience/studyGroupLessons/issues/7/comments","events_url":"https://api.github.com/repos/mozillascience/studyGroupLessons/issues/7/events","html_url":"https://github.com/mozillascience/studyGroupLessons/issues/7","id":98286303,"number":7,"title":"Open Science Utility Belt","user":{"login":"BillMills","id":1896943,"avatar_url":"https://avatars.githubusercontent.com/u/1896943?v=3","gravatar_id":"","url":"https://api.github.com/users/BillMills","html_url":"https://github.com/BillMills","followers_url":"https://api.github.com/users/BillMills/followers","following_url":"https://api.github.com/users/BillMills/following{/other_user}","gists_url":"https://api.github.com/users/BillMills/gists{/gist_id}","starred_url":"https://api.github.com/users/BillMills/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/BillMills/subscriptions","organizations_url":"https://api.github.com/users/BillMills/orgs","repos_url":"https://api.github.com/users/BillMills/repos","events_url":"https://api.github.com/users/BillMills/events{/privacy}","received_events_url":"https://api.github.com/users/BillMills/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":47,"created_at":"2015-07-30T23:32:59Z","updated_at":"2015-08-17T17:56:15Z","closed_at":null,"body":"## Open Science 101\r\n\r\nThis is a session series introducing practical skills needed to get started in open science. A [Mozilla Science Study Group](http://mozillascience.github.io/studyGroupHandbook/) can use this series to introduce open science over an academic semester.\r\n\r\n### Help Us Develop This Curriculum\r\n\r\nWe're trying to answer these questions:\r\n\r\n - What skills are needed to practice open science?\r\n - What's missing / What's unnecessary? (aiming for < 12 sessions over a semester)\r\n - What's out there now? References! If you've seen related material, send it over.\r\n\r\nLet us know your thoughts in the comments!\r\n\r\n### Sessions\r\n\r\n1. **Introduction: what & why**\r\n  - What skills will be part of this series?\r\n    - working openly through the entire process (not just warehousing things on the web afterwards) in order to leverage *collaboration*\r\n    - emphasizing legibility of research outputs for the sake of *reuse* & *reproducibility* \r\n  - Why do these things matter?\r\n    - lit review on citation benefits, efficacy benefits, retraction scandals & efficiency.\r\n  - Sources: Working Open guide, TBD\r\n\r\n2. **Open Data I: Standards & Legibility**\r\n  - What is an ontology?\r\n  - How to effectively use data standards and make data legible?\r\n  - Sources: TBD\r\n\r\n3. **Open Data II: Clean Data**\r\n  - What is 'clean' vs 'dirty' data, and why do they matter?\r\n    - how to keep data organized and easy to reuse at a later date (including in-house reuse); consider metadata, storage and formats.\r\n  - Best practices for making a reusable dataset when no standard exists.\r\n  - Sources: TBD\r\n\r\n4. **Collaboration I: Version Control**\r\n  - Basic git, with an emphasis on getting to GitHub as a platform for sharing & collaboration.\r\n  - Source: TBD\r\n\r\n5. **Collaboration II: Roadmapping**\r\n  - How to lay out a project for effective collaboration.\r\n  - Source: Working Open guide.\r\n\r\n6. **Collaboration III: Code Review**\r\n  - How to set expectations for good contributions that lead to easy-to-review code\r\n  - How to make the code review process fast and efficient\r\n  - Source: Working Open guide, [Code Review Teaching Kit](http://mozillascience.github.io/codeReview/intro.html)\r\n\r\n7. **Code Wrangling I: Sustainable Coding**\r\n  - Effective use of documentation.\r\n  - Understanding the impact of scope and modularity on code longevity & maintainability.\r\n  - Sources: TBD\r\n\r\n8. **Code Wrangling II: Testing**\r\n  - Writing test suites to ensure code quality & build trust to support reuse.\r\n  - Sources: [this lesson in Python](https://github.com/BillMills/python-testing), TBD in R.\r\n\r\n9. **Code Wrangling III: Code Packaging**\r\n  - Making & distributing packages to support reuse & collaboration.\r\n    - discussion of useful formalisms for organizing data & code in packages / repos\r\n  - Sources: [this lesson in Python](https://github.com/BillMills/pythonPackageLesson), and [this lesson in R](https://github.com/kazi11/TestPackage)\r\n\r\n10. **Publishing & Communication I: Citation & Discoverability**\r\n  - Software & data citation\r\n    - DOIs\r\n    - comments on how this addresses discoverability of code & data\r\n  - Authoring for the Web\r\n    - markdown / knittr\r\n    - metadata\r\n  - Sources: Working Open guide, TBD\r\n\r\n11. **Publishing & Communication II: The Research Cycle**\r\n  - Strategies for opening the entire research process:\r\n    - Grant process\r\n    - Online lab notebooks\r\n    - blogging, twitter & social media\r\n    - protocol publishing\r\n    - study pre-registration\r\n\r\n12. **Publishing & Communication III: Licensing**\r\n  - open access publishing\r\n    - comments on impact on science in the Global South / decoupling access from privilege\r\n  - Why are licenses necessary?\r\n  - What can they do? What can't they do?\r\n  - Which ones are the most important and how do they work?\r\n  - How to choose a license, and the intersection of licensing and copyright\r\n  - The importance of agreeing on a license explicitly and early on a collaboration\r\n  - sources: TBD"},"comment":{"url":"https://api.github.com/repos/mozillascience/studyGroupLessons/issues/comments/131909415","html_url":"https://github.com/mozillascience/studyGroupLessons/issues/7#issuecomment-131909415","issue_url":"https://api.github.com/repos/mozillascience/studyGroupLessons/issues/7","id":131909415,"user":{"login":"cboettig","id":222586,"avatar_url":"https://avatars.githubusercontent.com/u/222586?v=3","gravatar_id":"","url":"https://api.github.com/users/cboettig","html_url":"https://github.com/cboettig","followers_url":"https://api.github.com/users/cboettig/followers","following_url":"https://api.github.com/users/cboettig/following{/other_user}","gists_url":"https://api.github.com/users/cboettig/gists{/gist_id}","starred_url":"https://api.github.com/users/cboettig/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/cboettig/subscriptions","organizations_url":"https://api.github.com/users/cboettig/orgs","repos_url":"https://api.github.com/users/cboettig/repos","events_url":"https://api.github.com/users/cboettig/events{/privacy}","received_events_url":"https://api.github.com/users/cboettig/received_events","type":"User","site_admin":false},"created_at":"2015-08-17T17:56:15Z","updated_at":"2015-08-17T17:56:15Z","body":"@sjackman Yes, I've often been in a similar situation and I've used that same strategy.  (Which is also handy if the journal only accepts Word).  \r\n\r\nAlternatively, you can also just paste the source (e.g. LaTeX / md / Rmd) into a word document and send that.  I've found this avoids some pitfalls of the pandoc conversion to Word (though this is improving), particularly where equations are concerned.  This strategy was introduced to me by a senior colleague who has long worked in LaTeX while collaborating successfully with many Word-only folks.  We've both found collaborators are perfectly happy to ignore the markup and just read + track-changes the text.  Of course Word is a terrible text-editor that may play havoc with some character encodings, so you cannot always copy-paste the changes whole cloth.  \r\n\r\nNeither approach is ideal of course. Several collaborators always return documents to me marked in pen anyway, so the question of output format becomes irrelevant. Paper is the great interoperable standard.  In the end, manually writing in the changes, as required by any of these approaches, doesn't take that much time and does force you to pay close attention.   "}}