docs(*): point PRs to development (accordproject#349)

* docs(README): include conditionalplugin
* docs(*): point PRs to development
* fix(docs): correct sync with development instruction

Signed-off-by: irmerk <jolenelanglinais@gmail.com>

CONTRIBUTING.md

@@ -1,8 +1,8 @@
-# Contributing to Cicero-UI
+# Contributing to Cicero UI
 
 > Thanks to the AngularJS team for the bulk of this text!
 
-We'd love for you to contribute to our source code and to make Cicero-UI even better than it is today! Here are the guidelines we'd like you to follow:
+We'd love for you to contribute to our source code and to make Cicero UI even better than it is today! Here are the guidelines we'd like you to follow:
 
 * [Code of Conduct][contribute.coc]
 * [Questions and Problems][contribute.question]
@@ -15,7 +15,7 @@ We'd love for you to contribute to our source code and to make Cicero-UI even be
 
 ## <a name="coc"></a> Code of Conduct
 
-Help us keep Cicero-UI open and inclusive. Please read and follow our [Code of Conduct][coc].
+Help us keep Cicero UI open and inclusive. Please read and follow our [Code of Conduct][coc].
 
 ## <a name="requests"></a> Questions, Bugs, Features
 
@@ -37,33 +37,27 @@ Other channels for support are:
 
 ### <a name="issue"></a> Found an Issue or Bug?
 
-If you find a bug in the source code, you can help us by submitting an issue to our [GitHub Repository][github]. Even better, you can submit a Pull Request with a fix.
+If you find a bug in the source code, you can help us by submitting an issue to our [GitHub Repository][github]. Even better, you can submit a Pull Request to our `development` branch with a fix.
 
 **Please see the **[**Submission Guidelines**][contribute.submit]** below.**
 
 ### <a name="feature"></a> Missing a Feature?
 
-You can request a new feature by [submitting an issue][github-issues] to our GitHub Repository.
+You can request a new feature by [submitting an issue][github-issues] to our GitHub Repository's `development` branch.
 
 If you would like to implement a new feature then consider what kind of change it is:
 
-* **Major Changes** that you wish to contribute to the project should be discussed first in an
+* **Major Changes** that you wish to contribute to the project should be discussed first in a [GitHub issue][github-issues] that clearly outlines the changes and benefits of the feature.
 
-  [GitHub issue][github-issues] that clearly outlines the changes and benefits of the feature.
-
-* **Small Changes** can directly be crafted and submitted to the [GitHub Repository][github]
-
-  as a Pull Request. See the section about [Pull Request Submission Guidelines][contribute.submitpr], and
-
-  for detailed information read the [core development documentation][developers].
+* **Small Changes** can directly be crafted and submitted to the [GitHub Repository][github]'s `development` branch as a Pull Request. See the section about [Pull Request Submission Guidelines][contribute.submitpr], and for detailed information read the [core development documentation][developers].
 
 ### <a name="docs"></a> Want a Doc Fix?
 
 Should you have a suggestion for the documentation, you can open an issue and outline the problem or improvement you have - however, creating the doc fix yourself is much better!
 
 If you want to help improve the docs, it's a good idea to let others know what you're working on to minimize duplication of effort. Create a new issue \(or comment on a related existing one\) to let others know what you're working on.
 
-If you're making a small change \(typo, phrasing\) don't worry about filing an issue first. Use the friendly blue "Improve this doc" button at the top right of the doc page to fork the repository in-place and make a quick change on the fly. The commit message is preformatted to the right type and scope, so you only have to add the description.
+If you're making a small change \(typo, phrasing\) don't worry about filing an issue first.
 
 For large fixes, please build and test the documentation before submitting the PR to be sure you haven't accidentally introduced any layout or formatting issues. You should also make sure that your commit message follows the [**Commit Message Guidelines**][developers.commits].
 
@@ -86,61 +80,60 @@ Before you submit your pull request consider the following guidelines:
 * Create the [development environment][developers.setup]
 * Make your changes in a new git branch:
 
-  ```text
-    git checkout -b name-issue-tracker-short-description master
+  ```bash
+    git checkout -b userName-issueTracker-shortDescription
   ```
 
-  Name can be initials or GitHub username. An example of this could be:
+  User name can be initials or GitHub username. An example of this could be:
 
-  ```text
-    git checkout -b irmerk-issue75-readme-typos master
+  ```bash
+    git checkout -b irmerk-issue75-readme-typos
   ```
 
 * Create your patch commit, **including appropriate test cases**.
 * Follow our [Coding Rules][developers.rules].
-* Ensure you provide a DCO sign-off for your commits using the -s option of git commit. For more information see [how this works][dcohow].
+* Ensure you provide a DCO sign-off for your commits using the `-s` option of git commit. For more information see [how this works][dcohow].
 * If the changes affect public APIs, change or add relevant [documentation][developers.documentation].
 * Run the [unit test suite][developers.unit-tests], and ensure that all tests pass.
+* Commit your changes using a descriptive commit message that follows our [commit message conventions][developers.commits]. Adherence to the [commit message conventions][developers.commits] is required, because release notes are generated from these messages.
 
-* Commit your changes using a descriptive commit message that follows our [commit message conventions][developers.commits]. Adherence to the [commit message conventions][developers.commits] is required, because release notes are automatically generated from these messages.
-
-  ```text
-    git commit -a
+  ```bash
+    git commit -a --signoff
   ```
 
   Note: the optional commit `-a` command line option will automatically "add" and "rm" edited files.
 
 * Before creating the Pull Request, ensure your branch sits on top of master (as opposed to branch off a branch). This ensures the reviewer will need only minimal effort to integrate your work by fast-forwarding master:
 
-  ```text
+  ```bash
     git rebase upstream/master
   ```
 
 * Last step before creating the Pull Request, package and run all tests a last time:
 
-  ```text
+  ```bash
     npm run test
   ```
 
 * Push your branch to GitHub:
 
-  ```text
-    git push origin name-issue-tracker-short-description
+  ```bash
+    git push origin userName-issueTracker-shortDescription
   ```
 
-* In GitHub, send a pull request to `cicero-ui:master` by following our [pull request conventions][developers.pullrequest]. This will trigger the check of the [Contributor License Agreement][contribute.cla] and the Travis integration.
+* In GitHub, send a pull request to `accordproject/cicero-ui:development` by following our [pull request conventions][developers.pullrequest]. This will trigger the check of the [Contributor License Agreement][contribute.cla] and the Travis integration.
 * If you find that the Travis integration has failed, look into the logs on Travis to find out if your changes caused test failures, the commit message was malformed etc. If you find that the tests failed or times out for unrelated reasons, you can ping a team member so that the build can be restarted.
 * If we suggest changes, then:
   * Make the required updates.
   * Re-run the test suite to ensure tests are still passing.
-  * Commit your changes to your branch \(e.g. `name-issue-tracker-short-description`\).
+  * Commit your changes to your branch \(e.g. `userName-issueTracker-shortDescription`\).
   * Push the changes to your GitHub repository \(this will update your Pull Request\).
 
     You can also amend the initial commits and force push them to the branch.
 
-    ```text
+    ```bash
     git rebase master -i
-    git push origin name-issue-tracker-short-description -f
+    git push origin userName-issueTracker-shortDescription -f
     ```
 
     This is generally easier to follow, but separate commits are useful if the Pull Request contains iterations that might be interesting to see side-by-side.
@@ -153,28 +146,28 @@ After your pull request is merged, you can safely delete your branch and pull th
 
 * Delete the remote branch on GitHub either through the GitHub web UI or your local shell as follows:
 
-  ```text
-    git push origin --delete name-issue-tracker-short-description
+  ```bash
+    git push origin --delete userName-issueTracker-shortDescription
   ```
 
 * Check out the master branch:
 
-  ```text
+  ```bash
     git checkout master -f
   ```
 
 * Delete the local branch:
 
-  ```text
-    git branch -D name-issue-tracker-short-description
+  ```bash
+    git branch -D userName-issueTracker-shortDescription
   ```
 
 * Update your master with the latest upstream version:
 
-  ```text
+  ```bash
     git checkout master
     git fetch --all --prune
-    git merge --ff-only upstream/master
+    git rebase upstream/development
     git push origin master
   ```
 

DEVELOPERS.md

@@ -1,4 +1,4 @@
-# Developing Cicero-UI
+# Developing Cicero UI
 
 * [Development Setup][developers.setup]
 * [Coding Rules][developers.rules]
@@ -7,12 +7,12 @@
 
 ## <a name="setup"> Development Setup
 
-This document describes how to set up your development environment to build and test Cicero-UI, and
+This document describes how to set up your development environment to build and test Cicero UI, and
 explains the basic mechanics of using `git`, `node`, `npm`.
 
 ### Installing Dependencies
 
-Before you can build Cicero-UI, you must install and configure the following dependencies on your
+Before you can build Cicero UI, you must install and configure the following dependencies on your
 machine:
 
 * [Git][git]: The [Github Guide to Installing Git][git-setup] is a good source of information.
@@ -24,27 +24,27 @@ machine:
   We recommend using [nvm][nvm] (or [nvm-windows][nvm-windows])
   to manage and install Node.js, which makes it easy to change the version of Node.js per project.
 
-### Forking Cicero-UI on Github
+### Forking Cicero UI on Github
 
-To contribute code to Cicero-UI, you must have a GitHub account so you can push code to your own
-fork of Cicero-UI and open Pull Requests in the [GitHub Repository][github].
+To contribute code to Cicero UI, you must have a GitHub account so you can push code to your own
+fork of Cicero UI and open Pull Requests in the [GitHub Repository][github].
 
 To create a Github account, follow the instructions [here][github-signup].
 Afterwards, go ahead and [fork][github-forking] the
-[main Cicero-UI repository][github].
+[main Cicero UI repository][github].
 
-### Building Cicero-UI
+### Building Cicero UI
 
-To build Cicero-UI, you clone the source code repository and use lerna to build:
+To build Cicero UI, you clone the source code repository and use lerna to build:
 
 ```shell
 # Clone your Github repository:
 git clone https://github.com/<github username>/cicero-ui.git
 
-# Go to the Cicero-UI directory:
+# Go to the Cicero UI directory:
 cd cicero-ui
 
-# Add the main Cicero-UI repository as an upstream remote to your repository:
+# Add the main Cicero UI repository as an upstream remote to your repository:
 git remote add upstream "https://github.com/accordproject/cicero-ui.git"
 
 # Install node.js dependencies:
@@ -56,9 +56,9 @@ npm install
 It is good practice to always keep your `origin/master` in sync with `upstream/master`. You don’t have to, but it makes your life easier. Do your work in branches of your fork, and periodically sync up your `master` with the `master` of `upstream` as follows. You should definitely do this before creating a pull request.
 
 ```shell
-    git fetch --all --prune
     git checkout master
-    git merge --ff-only upstream/master
+    git fetch --all --prune
+    git rebase upstream/development
     git push origin master
 ```
 
@@ -85,7 +85,7 @@ To ensure consistency throughout the source code, keep these rules in mind as yo
 
 We have very precise rules over how our git commit messages can be formatted.  This leads to **more
 readable messages** that are easy to follow when looking through the **project history** and **git logs**.  
-But also, we use the git commit messages to **generate the Cicero-UI change log**.
+But also, we use the git commit messages to **generate the Cicero UI change log and release notes**.
 
 The commit message formatting can be added using a version of typical git workflow.
 
@@ -160,18 +160,18 @@ Formatting for the body is displayed in this example:
 - Link any issues or pull requests relating to this
 ```
 
-When approved and ready to merge, a Pull Request should be squashed down to a single buildable commit and merged into master.
+When approved and ready to merge, a Pull Request should be squashed down to a single buildable commit and merged into `development`.
 
 ## <a name="documentation"></a> Writing Documentation
 
-The Cicero-UI project uses [jsdoc][jsdoc] for all of its code
+The Cicero UI project uses [jsdoc][jsdoc] for all of its code
 documentation.
 
 This means that all the docs are stored inline in the source code and so are kept in sync as it
 changes.
 
 This means that since we generate the documentation from the source code, we can easily provide
-version-specific documentation by simply checking out a version of Cicero-UI and running the build.
+version-specific documentation by simply checking out a version of Cicero UI and running the build.
 
 ## License <a name="license"></a>
 

README.md

@@ -25,6 +25,7 @@ Components ready for use:
 Available Plugins:
 - [`ClausePlugin`][clauseplugin]
 - [`VariablePlugin`][variableplugin]
+- [`ConditionalPlugin`][conditionalplugin]
 - [`ComputedPlugin`][computedplugin]
 
 Components still in development:
@@ -90,6 +91,7 @@ Top level repository (cicero-ui), with sub packages. The entire package is publi
 - `TemplateLoadingClauseEditor`:
 - [`ClausePlugin`][clauseplugin]: A custom Slate plugin for embedding a clause node within a document
 - [`VariablePlugin`][variableplugin]: A custom Slate plugin for using editable, highlighted variables within a clause
+- [`ConditionalPlugin`][conditionalplugin]: A custom Slate plugin for using non-editable but toggle-able, conditional variables within a clause
 - [`ComputedPlugin`][computedplugin]: A custom Slate plugin for using non-editable, highlighted computed fields within a clause
 
 ---
@@ -369,6 +371,7 @@ Copyright 2018-2019 Clause, Inc. All trademarks are the property of their respec
 [templateloadingclauseeditor]: src/TemplateLoadingClauseEditor/README.md
 [clauseplugin]: src/plugins/README.md#clauseplugin
 [variableplugin]: src/plugins/README.md#variableplugin
+[conditionalplugin]: src/plugins/README.md#conditionalplugin
 [computedplugin]: src/plugins/README.md#computedplugin
 
 [cicero]: https://github.com/accordproject/cicero