Documentation

+srv/stimulusControllers.m

@@ -1,6 +1,26 @@
 function sc = stimulusControllers
 %SRV.STIMULUSCONTROLLERS Load all configured remote stimulus controllers
-%   TODO. See also SRV.STIMULUSCONTROL.
+%   Loads the remote rigs available to mc.  The configured controllers are
+%   expected to be an array of srv.StimulusControl objects named
+%   'stimulusControllers', loaded from a file called 'remote.mat' in the
+%   paths globalConfig directory.  The list is returned ordered
+%   alphabetically by the Name property.
+%
+%   Output:
+%     An array of srv.StimulusControl objects
+%
+%   Examples:
+%     % Save a couple of configurations for loading with this function
+%     stimulusControllers = [
+%       srv.StimulusControl.create('BigRig', 'ws://desktop-187'),
+%       srv.StimulusControl.create('TestRig')];
+%     configDir = getOr(dat.paths, 'globalConfig');
+%     save(fullfile(configDir, 'remote.mat'), 'stimulusControllers')
+%     
+%     % Load the stimulus controllers from file
+%     sc = srv.stimulusControllers;
+%
+% See also SRV.STIMULUSCONTROL, EUI.MCONTROL
 %
 % Part of Rigbox
 

.github/config.yml

@@ -6,4 +6,4 @@ todo:
         caseSensitive: false
         label: true
         reopenClosed: true
-        exclude: null
+        exclude: '.*.html$'

CONTRIBUTING.md

@@ -1,14 +1,14 @@
-When contributing to this repository, please first discuss the change you wish to make via creation of a [github issue](https://github.com/cortex-lab/Rigbox/issues) (preferred), or email with the [project maintainers](#project-maintainers). The purpose of this document is NOT meant to overwhelm potential contributors; rather, it is to establish a protcol for the project maintainers to follow when they are reviewing new code. Contributors should not feel like they must adhere to every point in this document without feedback or advice before submitting a pull request: contributors should feel at ease submitting pull requests and using this document as a reference, and it is the project maintainers' roles to work with contributors to ensure new code adheres to the guidelines defined in this document, including the [Code of Conduct](#code-of-conduct).
+When contributing to this repository, please first discuss the change you wish to make via creation of a [github issue](https://github.com/cortex-lab/Rigbox/issues) (preferred), or email with the [project maintainers](#project-maintainers).  Contributors should feel at ease submitting pull requests and using this document as a reference, and it is the project maintainers' roles to work with contributors to ensure new code adheres to the guidelines defined in this document, including the [Code of Conduct](#code-of-conduct).
 
-For contributing new code to this repository, we roughly follow a [gitflow workflow](https://nvie.com/posts/a-successful-git-branching-model). We also support [forking workflows](https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow) for contributors who wish to fork this repository and maintain their own local versions. 
+For contributing new code to this repository, we roughly follow a [git feature branch workflow](https://nvie.com/posts/a-successful-git-branching-model). We also support [forking workflows](https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow) for contributors who wish to fork this repository and maintain their own local versions. 
 
 Rigbox relies on the [signals](https://github.com/cortex-lab/signals) and [alyx-matlab](https://github.com/cortex-lab/alyx-matlab) repositories as submodules for designing and running behavioral tasks, and communicating with an [Alyx](https://github.com/cortex-lab/alyx) database, respectively. For contributors who are unfamiliar with repositories with submodules, please read this helpful [blog post.](https://github.blog/2016-02-01-working-with-submodules/)
 
 ## Contributing - Our Pull Request Process
 
 Following the gitflow workflow, Rigbox and its main submodules (signals, alyx-matlab, and wheelAnalysis) each have two main branches: the `dev` branch is where new features are deployed, and the `master` branch contains the stable build that most users will work with. Contributors should create a new "feature" branch for any changes/additions they wish to make, and then create a pull request for this feature branch. If making a change to a submodule, a pull request should be sent to that submodule's repository. (e.g. if a user is making a change to a file within the signals repository, a pull request should be made to the [signals repository](https://github.com/cortex-lab/signals/pulls), not to the Rigbox repository.) **All pull requests should be made to the `dev` branch of the appropriate repository.** All pull requests will be reviewed by the project maintainers. Below are procedural guidelines to follow for contributing via a pull request:
 
-1. Ensure any new file follows [MATLAB documentation guidelines](https://www.mathworks.com/help/matlab/matlab_prog/add-help-for-your-program.html) and is accompanied by a test file that adequately covers all expected use cases. This test file should be placed in the appropriate repository's `tests` folder, and follow the naming convention of `<newFile>_test`. If the contributor is not adding a new file but instead changing/adding to an exisiting file that already has an accompanying test file, a test that accompanies the contributor's code should be added to the existing test file. See the [Rigbox/tests folder](https://github.com/cortex-lab/Rigbox/tree/dev/tests) for examples. 
+1. Ensure any new file follows [MATLAB documentation guidelines](https://www.mathworks.com/help/matlab/matlab_prog/add-help-for-your-program.html) and is accompanied by a test file that adequately covers all expected use cases. This test file should be placed in the appropriate repository's `tests` folder, and follow the naming convention of `<newFile>_test`. If the contributor is not adding a new file but instead changing/adding to an exisiting file that already has an accompanying test file, a test that accompanies the contributor's code should be added to the existing test file. See the [Rigbox/tests folder](https://github.com/cortex-lab/Rigbox/blob/master/tests) for examples. 
 
 	*Note: For users unfamiliar with creating unit tests in MATLAB, [MATLAB's Testing Frameworks documentation](https://uk.mathworks.com/help/matlab/matlab-unit-test-framework.html?s_tid=CRUX_lftnav) has examples for writing [script-based](https://uk.mathworks.com/help/matlab/matlab_prog/write-script-based-unit-tests.html), [function-based](https://uk.mathworks.com/help/matlab/matlab_prog/write-simple-test-case-with-functions.html), and [class-based](https://uk.mathworks.com/help/matlab/matlab_prog/write-simple-test-case-using-classes.html) unit tests. The project maintainers are also happy to provide more specific test-related information and help contributors write tests.*
 
@@ -22,12 +22,12 @@ Following the gitflow workflow, Rigbox and its main submodules (signals, alyx-ma
 
 4. Create a pull request to merge the contributed branch into the `dev` branch. The submodule dependencies should be first checked and updated, if necessary. The branch will then be merged upon approval by at least one authorized reviewer.  We have a continuous integration server that checks that runs tests and checks for changes in code coverage.
 
-5. The project maintainers will typically squash the feature branch down to the commmit where it branched off from the `dev` branch, rebase the squashed branch onto `dev`, and then merge the rebased branch into `dev` (See [here](https://blog.carbonfive.com/2017/08/28/always-squash-and-rebase-your-git-commits) for more info on why to adopt the "squash, rebase, merge" workflow). When the project maintainers have merged the contributor's feature branch into the `dev` branch, the changes should be added to the [changelog](https://github.com/cortex-lab/Rigbox/blob/dev/CHANGELOG.md). When the `dev` branch has accumulated sufficient changes for it to be considered a new major version, and all changes have been deployed for at least a week, the project maintainers will open a pull request to merge `dev` into the `master` branch. The project maintainers should ensure that the version numbers in any relevant files and the `README` are up-to-date. The versioning specification numbering used is [SemVer](http://semver.org/). Previous versions are archived in [releases](https://github.com/cortex-lab/Rigbox/releases). Once the dev branch has accumulated sufficient changes for it to be considered a new major version, and all changes have been deployed for at least a week, the project maintainers will open a pull request to merge dev into the master branch.
+5. The project maintainers will typically squash the feature branch down to the commmit where it branched off from the `dev` branch, rebase the squashed branch onto `dev`, and then merge the rebased branch into `dev` (See [here](https://blog.carbonfive.com/2017/08/28/always-squash-and-rebase-your-git-commits) for more info on why to adopt the "squash, rebase, merge" workflow). When the project maintainers have merged the contributor's feature branch into the `dev` branch, the changes should be added to the [changelog](https://github.com/cortex-lab/Rigbox/blob/master/CHANGELOG.md). When the `dev` branch has accumulated sufficient changes for it to be considered a new major version, and all changes have been deployed for at least a week, the project maintainers will open a pull request to merge `dev` into the `master` branch. The project maintainers should ensure that the version numbers in any relevant files and the `README` are up-to-date. The versioning specification numbering used is [SemVer](http://semver.org/). Previous versions are archived in [releases](https://github.com/cortex-lab/Rigbox/releases). Once the dev branch has accumulated sufficient changes for it to be considered a new major version, and all changes have been deployed for at least a week, the project maintainers will open a pull request to merge dev into the master branch.
 
 ## Style Guidelines
 
 [Richard Johnson](https://uk.mathworks.com/matlabcentral/profile/authors/22731-richard-johnson) writes, "Style guidelines are not commandments. Their goal is simply to help programmers write well." Well-written code implies code that is easy to read. Code that is easy to read is typically written in a consistent style, so we suggest making your code as consistent with the rest of the repository as possible. Some examples:
-* For a particularly well-documented function, see ['sig.timeplot'](https://github.com/cortex-lab/signals/blob/dev/%2Bsig/timeplot.m). For a particularly well-documented class, see ['hw.Timeline'](https://github.com/cortex-lab/Rigbox/blob/dev/%2Bhw/Timeline.m) 
+* For a particularly well-documented function, see ['sig.timeplot'](https://github.com/cortex-lab/signals/blob/master/%2Bsig/%2Btest/timeplot.m). For a particularly well-documented class, see ['hw.Timeline'](https://github.com/cortex-lab/Rigbox/blob/master/%2Bhw/Timeline.m) 
 * File header documentation is written as follows (see the above files for examples):
 	- Functions have (in the following order): a one-line summary describing the action of the function, a longer description, details on their inputs and outputs, examples, and any additional notes.
 	- Classes have (in the following order): a one-line summary of the class, a longer description, examples, and any additional notes.