Merge pull request #22 from pbchase/grammar_check_index

Update guide_for_admins_and_devs for slide deck

docs/guide_for_admins_and_devs.md

@@ -16,7 +16,7 @@ External Modules--referred to hereafter as simply *modules*--were introduced as
 
 The first sanctioned method for extending REDCap was *plugins*. The REDCap developers introduced plugins in REDCap 4.6.0 in 2011. In REDCap, a plugin is an entirely new page in the REDCap web app. REDCap admins would often present the plugin in the left-hand sidebar via the Bookmark feature in REDCap.
 
-REDCap 5.11.0 introduced the *hook* extension in May 2014, though that was just a rebranding of REDCap Extensions from REDCap 5.8.0, which, in turn, was a rebranding of Custom REDCap Functions from who knows when. The role of a hook is to allow custom code to modify and existing REDCap page without changing the REDCap core code. A hook is a named function which--if it exists--will be called during a page load. Typically, REDCap calls the hook function at the beginning of the page construction or the very end. Hook functions can be pure PHP, just enough PHP to load some novel JavaScript, or a mixture of PHP and JavaScript.
+REDCap 5.11.0 introduced the *hook* extension in May 2014, though that was just a rebranding of REDCap Extensions from REDCap 5.8.0, which, in turn, was a rebranding of Custom REDCap Functions from who knows when. The role of a hook is to allow custom code to modify an existing REDCap page without changing the REDCap core code. A hook is a named function which--if it exists--will be called during a page load. Typically, REDCap calls the hook function at the beginning of the page construction or the very end. Hook functions can be pure PHP, just enough PHP to load some novel JavaScript, or a mixture of PHP and JavaScript.
 
 Hooks and plugins are relevant to modules because both concepts live on within modules. Their history influenced the module framework and Vanderbilt's rules used for developing modules. Their history also explains why they are on the way out as standalone extension methods.
 
@@ -155,7 +155,7 @@ Yet there remains a tendency for people to think their code is not good enough t
 
 Once the coding starts, REDCap Admins and developers have to work together on the shared mission of making useful REDCap modules. Github provides excellent tools to aid that collaboration. Github has documented those tools in the [GitHub Guides](https://guides.github.com/). The most important of these is [Understanding the GitHub flow](https://guides.github.com/introduction/flow/) as it teaches the concepts behind GitHub's tools. If you don't already know _Markdown_, also read [Mastering Markdown](https://guides.github.com/features/mastering-markdown/). Markdown should be your go-to language for documenting your module from the `README.md` file to the text of Github issues and comments. Everyone--REDCap Admins and developer--should know the basics of Markdown.
 
-A reviewer needs to inspect every change to a module. The reviewer offers a different perspective on how the software should work, whether it works, if the documentation makes sense, or if the code is unclear. A good testing workflow forces the author to commit changes into a git repo while the tester checkouts out those changes and reviews the work in a different computer without asking the author questions. This process assures the repo has all the changes the author intended and the documentation to implement those changes.
+A reviewer needs to inspect every change to a module. The reviewer offers a different perspective on how the software should work, whether it works, if the documentation makes sense, or if the code is unclear. A good testing workflow forces the author to commit changes into a git repo while the tester checks out those changes and reviews the work in a different computer without asking the author questions. This process assures the repo has all the changes the author intended and the documentation to implement those changes.
 
 The rule about using a different computer is *extremely* important. This constraint will help the team avoid the dreaded "It works on my machine" syndrome when the module moves to production. Every member of the team can have their own "different computer" by using the [REDCap Docker Compose Environment](https://github.com/123andy/redcap-docker-compose). This software helps you build a personal REDCap on your computer. redcap-docker-compose is built on a technology called _Docker_ that allows a user to create a local REDCap host in seconds. After that, a web-based installer allows the user to install and configure a REDCap instance in about a minute. The [Developer Guide](guide_for_devs/) builds upon this environment with 
 instructions for checking out a module to make it available to REDCap Docker Compose in [Setting Up Your Environment](guide_for_devs/#setting-up-your-environment).
@@ -171,7 +171,7 @@ Wherever they test, REDCap Admins must check the new module before they install
 
 There is considerable value in sharing the ideas and software extensions that modify REDCap. Yet the software will not share itself. Any team making modules or any other extension for REDCap needs to be proactive on a few fronts.
 
-While Vanderbilt requires an open-source license to publish a module in the REDCap Repo, the license is essential in _any_ software another team might use. You should proactively place an open source license on your software project if you plan to share it. An open-source license protects the consumer's freedom to use, reuse, and adapt the software. Should the creator of the software lose interest in maintaining it, the software maintenance burden might need to shift to someone else. An open-source license provides legal freedom for another team to do that. At the same time, the open-source license protects the rights of collaborators and contributors to modify the software, use it, and share those modifications. Protect other teams' rights to use your creation by putting an open source license on the software from day one. It communicates your intent to build something to be shared by the community.
+While Vanderbilt requires an open-source license to publish a module in the REDCap Repo, the license is essential in _any_ software another team might use. You should proactively place an open source license on your software project if you plan to share it. An open-source license protects the consumer's freedom to use and adapt the software. Should the creator of the software lose interest in maintaining it, the software maintenance burden might need to shift to someone else. An open-source license provides legal freedom for another team to do that. At the same time, the open-source license protects the rights of collaborators and contributors to modify the software, use it, and share those modifications. Protect other teams' rights to use your creation by putting an open source license on the software from day one. It communicates your intent to build something to be shared by the community.
 
 Eventually, your work needs to be released, deployed, and published. Releasing is the process by which you formally say, "This idea is whole and functional." An entry in a ChangeLog or a version number is a good way to communicate that your product, its new feature, or a bug fix is ready for use. An entry in a ChangeLog file is the right place to summarize what has changed since the previous release and put a version number on those changes. A version number _tag_ in the commit history is a great way to communicate to GitHub and future developers exactly when and where that happened. These events describe a _release_.
 

docs/index.md

@@ -3,9 +3,8 @@ layout: default
 title: REDCap External Module Development Guide
 ---
 
-# REDCap External Module  Development Guide
+# REDCap External Module Development Guide
 
-This site is a guide to the development of software extensions to Vanderbilt University's Research Electronic Data CAPture (REDCap) using REDCap's External Module framework. Added to REDCap in the Fall of 2018, the external module framework has proven to be an effective an popular way to change REDCap's behavior to meet the needs of specific sites and projects. This guide provides an introduction to external modules and  guidance in creating a team and plan for developing modules for one's own needs and the larger REDCap community.
-
-The audience for this guide is both REDCap Admins and software developers who would be writing the modules. The guide is split into a two sections to address the different audiences. The first section, [REDCap External Module Development for REDCap Admins and Developers](guide_for_admins_and_devs), provides the background both audiences need to work together to create and share a module with the REDCap community. The second section, [REDCap External Module Development for Developers](guide_for_devs), provides guidance to developers on how to write the module code, REDCap classes, and resources for module development. The developer's guide is primarily composed of a series of exercises to create simple modules that extend REDCap in different ways.
+This site is a guide to the development of software extensions to Vanderbilt University's Research Electronic Data CAPture (REDCap) using REDCap's External Module framework. Added to REDCap in the Fall of 2017, the external module framework has proven to be an effective and popular way to change REDCap's behavior to meet the needs of specific sites and projects. This guide provides an introduction to external modules and guidance in creating a team and plan for developing modules for one's own needs and the broader REDCap community.
 
+The audience for this guide is both REDCap Admins and software developers who would be writing the modules. The guide is split into two sections to address the different audiences. The first section, [REDCap External Module Development for REDCap Admins and Developers](guide_for_admins_and_devs), provides the background both audiences need to work together to create and share a module with the REDCap community. The second section, [REDCap External Module Development for Developers](guide_for_devs), guides developers to the right development tools, suggests resources for module development and offers coding exercises to create simple modules that make use of the various tools at the disposal of an External Module developer.