eliminate unnecessary backslash-escaped quotes

docs/contrib/branching.md

@@ -54,8 +54,8 @@ Because only releases are merged back, the `master` branch always represent the
 ## New Development Branches
 
 Immediately after a release, one or more new branches are created.
-Typically after a major \'1.0.0\' release, there will be two branches created.
+Typically after a major '1.0.0' release, there will be two branches created.
-First the \'1.0.1\' branch is a patch development branch, intended to be used if an emergency patch is required.
+First the '1.0.1' branch is a patch development branch, intended to be used if an emergency patch is required.
 It therefore sits unused until an emergency arises.
 No work is performed on a patch development branch.
 

docs/contrib/build.md

@@ -6,7 +6,7 @@ This is for developers.
 Specifically those who know how to use tools, satisfy dependencies, and want to set up a development environment.
 It is not user-friendly.
 
-You\'ll need these tools:
+You'll need these tools:
 
 -   [git](https://git-scm.com/)
 -   [cmake](https://cmake.org)
@@ -15,7 +15,7 @@ You\'ll need these tools:
 -   Python 2.7 or later (for tests)
 -   Bash (for tests)
 
-You\'ll need these libraries:
+You'll need these libraries:
 
 -   [GnuTLS](https://www.gnutls.org/)
 -   libuuid (unless on Darwin/BSD)

docs/contrib/contribute.md

@@ -4,7 +4,7 @@ title: Contributing to Taskwarrior
 
 Help is needed in all areas of Taskwarrior development - design, coding, testing, support and marketing.
 Applicants must be friendly.
-Perhaps you are looking to help, but don\'t know where to start.
+Perhaps you are looking to help, but don't know where to start.
 You can of course [email us](mailto:taskwarrior-dev@googlegroups.com) but take a look at this list.
 Perhaps you have skills we are looking for, here are ways you may be able to help:
 
@@ -13,10 +13,10 @@ Perhaps you have skills we are looking for, here are ways you may be able to hel
     New users have a fresh approach that we can no longer achieve, while veteran users develop clever and crafty ways to use the product.
 
 -   Report bugs and odd behavior when you see it.
-    We don\'t necessarily know it\'s broken, unless you tell us.
+    We don't necessarily know it's broken, unless you tell us.
 
 -   Suggest enhancements.
-    We get lots of these, and it\'s great.
+    We get lots of these, and it's great.
     Some really good ideas have been suggested and implemented.
     Sure, some are out of scope, or plain crazy, but the stream of suggestions is fascinating to think about.
 
@@ -45,7 +45,7 @@ Perhaps you have skills we are looking for, here are ways you may be able to hel
 
 -   Fix a bug.
     Send a patch.
-    You\'ll need C++ skills for this.
+    You'll need C++ skills for this.
 
 -   Write a unit test.
     Improve an existing unit test.
@@ -55,8 +55,8 @@ Perhaps you have skills we are looking for, here are ways you may be able to hel
     Share your methodology, to inspire others.
 
 -   Encouragement.
-    Tell us what works for you, and what doesn\'t.
+    Tell us what works for you, and what doesn't.
-    It\'s all good.
+    It's all good.
 
 -   Donate! Help offset costs.
 

docs/contrib/first_time.md

@@ -4,7 +4,7 @@ title: How to become an Open Source Contributor
 
 Welcome, potential new Open Source contributor! This is a guide to show you exactly how to make a contribution, and will lead you through the entire process.
 
-There are many people who wish to start contributing, but don\'t know how or where to start.
+There are many people who wish to start contributing, but don't know how or where to start.
 If this might be the case, then please read on, this guide is for you.
 Because we want you to join in the fun with Open Source - it can be fun and rewarding, improve your skills, or just give you a way to contribute back to a project.
 
@@ -13,7 +13,7 @@ Where else can you combine the thrill of typing in a darkened room with the kind
 The goal of this document is to give you the ability to make your first contribution, and encourage you to make a second, by showing you how simple it is.
 Perhaps confidence and a little familiarity with the process are all you need to get started.
 
-We\'re going to pick the smallest contribution of all - a typo fix.
+We're going to pick the smallest contribution of all - a typo fix.
 While this may be a very small improvement, it is nevertheless a wanted improvement, and will be welcomed.
 Fixes such as this happen many times a day.
 Similar work on new features, new documents, rewriting help, refactoring code, fixing bugs and improving performance all combine to make a project grow and improve.
@@ -26,7 +26,7 @@ Get all the way to the end, and you will be an open source contributor.
 ## [1] Development Environment Setup
 
 In order to build and test software, you need a development environment.
-That\'s just a term that means you need certain tools installed before proceeding.
+That's just a term that means you need certain tools installed before proceeding.
 Here are the tools that Taskwarrior needs:
 
 -   Compiler: GCC 4.7 or newer, or Clang 3.4 or newer.
@@ -61,7 +61,7 @@ This involves cloning the repository using git and looking at the development br
 The URL for the repository was obtained from looking around on <https://github.com/GothenburgBitFactory> where several repositories are public, including the one for this web site.
 
 The clone command above puts you on the right branch, so no need to switch.
-But it\'s a good idea to check anyway, so do this:
+But it's a good idea to check anyway, so do this:
 
     $ cd taskwarrior.git
     $ git branch -a
@@ -76,13 +76,13 @@ If there were a higher numbered branch, you would want to use that by doing this
 
     $ git checkout 2.7.0
 
-Here\'s a thought - if this page does not show the latest branch names, then, you know, you could fix that\...
+Here's a thought - if this page does not show the latest branch names, then, you know, you could fix that\...
 
 
 ## [3] Fix Something
 
 Now that you have the code, find something to fix.
-This may be the hardest step, but knowing how many typos there are in the source code and docs, it shouldn\'t take long to find one.
+This may be the hardest step, but knowing how many typos there are in the source code and docs, it shouldn't take long to find one.
 Try looking in the files in these directories:
 
 -   `taskwarrior.git/doc/man`
@@ -90,8 +90,8 @@ Try looking in the files in these directories:
 -   `taskwarrior.git/src`
 -   `taskwarrior.git/test`
 
-It also doesn\'t need to be a typo, it can instead be a poorly-worded sentence, or one that could be more clear.
+It also doesn't need to be a typo, it can instead be a poorly-worded sentence, or one that could be more clear.
-You\'ll find something, whether it is jargon, mixed tenses, mistakes, or just plain wrong.
+You'll find something, whether it is jargon, mixed tenses, mistakes, or just plain wrong.
 
 Then fix it, using a text editor.
 Try to make the smallest possible change to achieve what you want, because smaller changeѕ are easier to verify and approve, and no reviewer wants to receive a large change to approve.
@@ -100,7 +100,7 @@ Try to make the smallest possible change to achieve what you want, because small
 ## [4] Run the Test Suite
 
 Taskwarrior has an extensive test suite to prove that things are still working as expected.
-You\'ll need to build the program and run this test suite in order to prove to yourself that your fix is good.
+You'll need to build the program and run this test suite in order to prove to yourself that your fix is good.
 It may seem like building the program is overkill, if you only make a small change, but no, it is not.
 The test suite is there to save you from submitting a bad change, and to save Taskwarrior from any mistakes you make.
 
@@ -176,7 +176,7 @@ This means all is well.
 
 ## [5] Commit the Change
 
-Now you\'ve made a change, built and tested the code.
+Now you've made a change, built and tested the code.
 The next step is to commit the change locally.
 This example assumes you fixed a typo in the man page.
 Check to see which file you changed, stage that file, then commit it:
@@ -216,7 +216,7 @@ Finally you just need to email that patch file to `taskwarrior-dev@googlegroups.
 You will need to attach it to an email, and not just paste it in, because the mail client will probably mess with the contents, wrapping lines etc, which can make it unusable.
 
 What happens next is that a developer will take your patch and study it, to ascertain whether it really does fix something that is broken.
-If there is a problem, you\'ll hear back with some gentle, constructive criticism.
+If there is a problem, you'll hear back with some gentle, constructive criticism.
 If the problem is small, it might just get fixed.
 Then your patch is applied, tested, and if all looks well, pushed to the public repository, and included in the the next release.
 Your name will go into the AUTHORS file, and you will be thanked.

docs/rfcs/cli.md

@@ -151,4 +151,4 @@ Aside from the command line parser, there are other changes needed:
         hhmmss       # Bad
         hh:mm:ss     # Good
 
--   The tutorial videos will be even more out of date, and will be replaced by a large number of smaller demo \'movies\'.
+-   The tutorial videos will be even more out of date, and will be replaced by a large number of smaller demo 'movies'.

docs/rfcs/client.md

@@ -23,7 +23,7 @@ The client will need proper credentials to talk to the server.
 
 In this document, we adopt the convention discussed in Section 1.3.2 of [RFC1122](https://tools.ietf.org/html/rfc1122#page-16) of using the capitalized words MUST, REQUIRED, SHOULD, RECOMMENDED, MAY, and OPTIONAL to define the significance of each particular requirement specified in this document.
 
-In brief: \"MUST\" (or \"REQUIRED\") means that the item is an absolute requirement of the specification; \"SHOULD\" (or \"RECOMMENDED\") means there may exist valid reasons for ignoring this item, but the full implications should be understood before doing so; and \"MAY\" (or \"OPTIONAL\") means that this item is optional, and may be omitted without careful consideration.
+In brief: "MUST" (or "REQUIRED") means that the item is an absolute requirement of the specification; "SHOULD" (or "RECOMMENDED") means there may exist valid reasons for ignoring this item, but the full implications should be understood before doing so; and "MAY" (or "OPTIONAL") means that this item is optional, and may be omitted without careful consideration.
 
 
 ## Taskserver Account
@@ -50,12 +50,12 @@ An example of this value is:
 
 In addition to a DNS name, this can be an IPv4 or IPv6 address.
 
-The organization name is an arbitrary grouping, and is typically \'PUBLIC\', reflecting the individual nature of server accounts.
+The organization name is an arbitrary grouping, and is typically 'PUBLIC', reflecting the individual nature of server accounts.
 Future capabilities will provide functionality that support groups of users, called an organization.
 
 The user name is the full name.
 This will be the name used to identify other users in an organization, in a future release.
-Example \'John Doe\'.
+Example 'John Doe'.
 
 The password is a text string generated by the server at account creation time.
 It should be considered a secret.
@@ -93,12 +93,12 @@ The client may use any library that supports the above.
 ## Configuration
 
 The client needs to store configuration, which matches the credentials needed for Taskserver communication.
-See section 2.1 \"Credentials\".
+See section 2.1 "Credentials".
 
 The credentials may not be modified by the user without losing server access.
 
 The server:port data may need to be changed automatically following a redirect response from the server.
-See section 5 \"Server Errors\".
+See section 5 "Server Errors".
 
 
 ## Local Storage
@@ -121,7 +121,7 @@ If a client performs too many sync operations, the server MAY revoke the certifi
 
 Effectively, the client should maintain a separate list of tasks changed since the last successful sync operation.
 
-Note that tasks have a \"modified\" attribute, which should be updated whenever a change is made.
+Note that tasks have a "modified" attribute, which should be updated whenever a change is made.
 This attribute contributes to conflict resolution on the server.
 
 
@@ -129,7 +129,7 @@ This attribute contributes to conflict resolution on the server.
 
 When a server sends remote changes to a client, in the response to a sync request, the changes have already been merged by the server, and therefore the client should simply store them intact.
 
-Based on the UUID in the task, the client can determine whether a task is new (and should be added to the local list of tasks), or whether it represents a modification (and should overwrite it\'s existing entry).
+Based on the UUID in the task, the client can determine whether a task is new (and should be added to the local list of tasks), or whether it represents a modification (and should overwrite it's existing entry).
 
 The client MUST NOT perform any merges.
 
@@ -145,11 +145,11 @@ If a client omits the sync key in a sync message, the response will be a complet
 
 ## Data Integrity
 
-Although a task is guaranteed to contain at least \'entry\', \'description\' and \'uuid\' attributes, it may also contain other known fields, and unknown user-defined fields.
+Although a task is guaranteed to contain at least 'entry', 'description' and 'uuid' attributes, it may also contain other known fields, and unknown user-defined fields.
-An example might be an attribute named \'estimate\'.
+An example might be an attribute named 'estimate'.
 
-If a task is received via sync that contains an attribute named \'estimate\', then a client has the responsibility of preserving the attribute intact.
+If a task is received via sync that contains an attribute named 'estimate', then a client has the responsibility of preserving the attribute intact.
-If that data is shown, then it is assumed to be of type \'string\', which is the format used by JSON for all values.
+If that data is shown, then it is assumed to be of type 'string', which is the format used by JSON for all values.
 
 Conversely, if a client wishes to add a custom attribute, it is guaranteed that the server and other clients will preserve that attribute.
 
@@ -170,7 +170,7 @@ The response message contains status and remote changes, which MUST be stored lo
 ## Establishing Encrypted Connection
 
 All communication with the Taskserver is encrypted using the certificate and key provided to each user.
-Using the \'server\' configuration setting, establish a connection.
+Using the 'server' configuration setting, establish a connection.
 
 
 ## Sync Request
@@ -182,7 +182,7 @@ A sync request MUST contain a list of modified tasks, in JSON format (see [Task
 
 ## Sync Response
 
-A sync response WILL contain a \'code\' and \'status\' header variable, WILL contain a sync key in the payload, and MAY contain a list of tasks from the server in JSON format (see [Task JSON](/docs/design/task)).
+A sync response WILL contain a 'code' and 'status' header variable, WILL contain a sync key in the payload, and MAY contain a list of tasks from the server in JSON format (see [Task JSON](/docs/design/task)).
 
 
 ## Server Messages
@@ -227,7 +227,7 @@ All errors consist of a code and a status message:
 Here are examples of properly formatted request and response messages.
 Note that the messages are indented for clarity in this document, but is not the case in a properly formatted message.
 Also note that newline characters U+000D are not shown, but are implied by the separate lines.
-Because some messages have trailing newline characters, the text is delimited by the \'cut\' markers:
+Because some messages have trailing newline characters, the text is delimited by the 'cut' markers:
 
     foo
 
@@ -344,7 +344,7 @@ Note the double newline character separating header from payload, with an empty
     status: Redirect
     info:
 
-Note the \'info\' field will contain a \':\' string that should be used for all future sync requests.
+Note the 'info' field will contain a ':' string that should be used for all future sync requests.
 This indicates that a user account was moved to another server.
 
 Note the double newline character separating header from payload, with an empty payload.

docs/rfcs/protocol.md

@@ -9,7 +9,7 @@ title: "Taskwarrior - Sync Protocol"
 ## Introduction
 
 Taskwarrior data has typically been shared in several ways.
-Those include SCM (source code management) systems, directory synchronizing software (such as DropBox), and by use of the \'push\', \'pull\' and \'merge\' commands introduced in version 1.9.3.
+Those include SCM (source code management) systems, directory synchronizing software (such as DropBox), and by use of the 'push', 'pull' and 'merge' commands introduced in version 1.9.3.
 
 While these methods work, they each have problems associated with the merging of data.
 In the case of directory synchronizing software, there is no merging at all - just simple file overwrite, despite many people believing that the data is somehow combined and preserved.
@@ -32,7 +32,7 @@ Other clients will follow.
 
 In this document, we adopt the convention discussed in Section 1.3.2 of [RFC1122](https://tools.ietf.org/html/rfc1122#page-16) of using the capitalized words MUST, REQUIRED, SHOULD, RECOMMENDED, MAY, and OPTIONAL to define the significance of each particular requirement specified in this document.
 
-In brief: \"MUST\" (or \"REQUIRED\") means that the item is an absolute requirement of the specification; \"SHOULD\" (or \"RECOMMENDED\") means there may exist valid reasons for ignoring this item, but the full implications should be understood before doing so; and \"MAY\" (or \"OPTIONAL\") means that this item is optional, and may be omitted without careful consideration.
+In brief: "MUST" (or "REQUIRED") means that the item is an absolute requirement of the specification; "SHOULD" (or "RECOMMENDED") means there may exist valid reasons for ignoring this item, but the full implications should be understood before doing so; and "MAY" (or "OPTIONAL") means that this item is optional, and may be omitted without careful consideration.
 
 
 ## Link Level
@@ -48,7 +48,7 @@ It does not perform any user interaction or presentation-level functions.
 ## Transactions
 
 Each transaction is a single incoming message, with a single response message.
-All communication therefore consists of a single \'send\', followed by a single \'receive\', then termination.
+All communication therefore consists of a single 'send', followed by a single 'receive', then termination.
 There are no sessions, and no continuously open connections.
 The message format is described in the [Taskserver Message Format](/docs/design/request) document.
 
@@ -70,17 +70,17 @@ This describes how Taskwarrior implements sync.
 All modifications to tasks (add, modify, done, delete \...) are recorded in the form of a fully-composed [JSON-formatted task](/docs/design/task).
 The formatted task is added to a local backlog.data file.
 If a task is modified a second time, it is added again to the backlog.data file - the lines are not combined.
-Each task SHALL have a \'modified\' date attribute that will help resolve conflicts.
+Each task SHALL have a 'modified' date attribute that will help resolve conflicts.
 
 On sync:
 
--   Send a \'sync\' type message with the entire contents of the backlog.data, unmodified, as the message payload.
+-   Send a 'sync' type message with the entire contents of the backlog.data, unmodified, as the message payload.
 
 -   Receive one of the following response codes:
 
-  -   201: This means \'no change\', and there is no further action to be taken.
+  -   201: This means 'no change', and there is no further action to be taken.
 
-  -   200: This means \'success\', and the message payload contains a set of tasks and a sync key:
+  -   200: This means 'success', and the message payload contains a set of tasks and a sync key:
 
     -   The formatted tasks are to be stored as-is.
         These tasks will either be appended to the client data or will overwrite existing client data, based on the UUID of the task.
@@ -88,9 +88,9 @@ On sync:
 
     -   The sync key will be written to the backlog.data file, overwriting the previous contents, such that it will now contain only one line.
 
-    -   301: Redirect to : found in the \'info\' response header, will force the client to resubmit the request to the new server.
+    -   301: Redirect to : found in the 'info' response header, will force the client to resubmit the request to the new server.
 
-    -   3xx, 4xx, 5xx: The \'status\' field contains an error message.
+    -   3xx, 4xx, 5xx: The 'status' field contains an error message.
 
 -   If the response contained any error or warning, the error should be shown to the user.
     This provides an opportunity for the server to announce downtime, or relocation.
@@ -98,7 +98,7 @@ On sync:
 If no sync key is sent, the server cannot provide an incremental delta, and so will send all task data, which should be stored as above.
 This should be the case for a client making its first sync call.
 
-If an unrecognized attribute is present in the task data, the client MUST preserve the attribute unmodified, and assume it is of type \'string\'.
+If an unrecognized attribute is present in the task data, the client MUST preserve the attribute unmodified, and assume it is of type 'string'.
 This permits individual clients to augment the task data without other clients stripping it meaningful data.
 This is how UDAs (user defined attributes) are handled.
 
@@ -110,7 +110,7 @@ This protocol was designed so that extensions to the protocol will take the form
 
 ## Summary of Response Codes
 
-Status responses indicate the server\'s response to the last command received from the client.
+Status responses indicate the server's response to the last command received from the client.
 The codes consist of a 3 digit numeric code.
 
 The first digit of the response broadly indicates the success, failure, or progress of the previous command (based generally on [RFC640](https://tools.ietf.org/html/rfc640) [RFC821](https://tools.ietf.org/html/rfc821)):

docs/rfcs/request.md

@@ -15,7 +15,7 @@ This document describes the message format, and the supported message types.
 
 In this document, we adopt the convention discussed in Section 1.3.2 of [RFC1122](https://tools.ietf.org/html/rfc1122#page-16) of using the capitalized words MUST, REQUIRED, SHOULD, RECOMMENDED, MAY, and OPTIONAL to define the significance of each particular requirement specified in this document.
 
-In brief: \"MUST\" (or \"REQUIRED\") means that the item is an absolute requirement of the specification; \"SHOULD\" (or \"RECOMMENDED\") means there may exist valid reasons for ignoring this item, but the full implications should be understood before doing so; and \"MAY\" (or \"OPTIONAL\") means that this item is optional, and may be omitted without careful consideration.
+In brief: "MUST" (or "REQUIRED") means that the item is an absolute requirement of the specification; "SHOULD" (or "RECOMMENDED") means there may exist valid reasons for ignoring this item, but the full implications should be understood before doing so; and "MAY" (or "OPTIONAL") means that this item is optional, and may be omitted without careful consideration.
 
 ## Encoding
 
@@ -23,7 +23,7 @@ All messages are UTF8-encoded text.
 
 ## Message Format
 
-This format is based on [RFC2822](https://tools.ietf.org/html/rfc2822), \'Internet Message Format\'.
+This format is based on [RFC2822](https://tools.ietf.org/html/rfc2822), 'Internet Message Format'.
 Here is an example of the format:
 
     <SIZE>
@@ -36,7 +36,7 @@ There are three sections.
 The first is the size, which is a 4-byte, big- Endian, binary byte count of the length of the message, including the 4 bytes for the size.
 
 The header section is a set of name/value pairs separated by newline characters (U+000D).
-The name is separated from the value by \': \' (colon U+003A, space U+0020) The header section is terminated by two consecutive newline (U+000D) characters.
+The name is separated from the value by ': ' (colon U+003A, space U+0020) The header section is terminated by two consecutive newline (U+000D) characters.
 All text is UTF8-encoded.
 
 The payload section is arbitrary, and message type-specific.
@@ -52,13 +52,13 @@ Those are:
 -   protocol
 -   client
 
-The \'type\' value is what determines the interpretation of the payload.
+The 'type' value is what determines the interpretation of the payload.
 
-The \'protocol\' value should be \'v1\', or any subsequently published protocol version.
+The 'protocol' value should be 'v1', or any subsequently published protocol version.
 
-The \'client\' represent the client identifier, so that any special cases can be handled.
+The 'client' represent the client identifier, so that any special cases can be handled.
 For example, an emergency fix that is client version-specific could be released, to support users that have not updated their client, or perhaps the client has not released a fix.
-The form of the \'version\' value is:
+The form of the 'version' value is:
 
     <product identifier> <version number>
 
@@ -72,7 +72,7 @@ If another client is spoofed, then patches addressing protocol errors may break
 
 ## Auth Data
 
-Every request from the client SHALL contain \"auth\" information, which involves these header entries:
+Every request from the client SHALL contain "auth" information, which involves these header entries:
 
     org: <organization>
     user: <user>
@@ -114,10 +114,10 @@ It is expected that the number of supported ticket types will increase over time
 
 ## Sync Message
 
-The \"sync\" message always originates from the client, but the response will contain data from the server.
+The "sync" message always originates from the client, but the response will contain data from the server.
 A sync is therefore a single request with a single response.
 
-The \"sync\" message type MUST contain the following headers:
+The "sync" message type MUST contain the following headers:
 
 -   type
 -   org
@@ -126,7 +126,7 @@ The \"sync\" message type MUST contain the following headers:
 -   client
 -   protocol
 
-The \"sync\" message payload has this format:
+The "sync" message payload has this format:
 
     <uuid>
     <JSON task 1>

docs/rfcs/rules.md

@@ -48,7 +48,7 @@ To prepare for a Rules System, various subsystems must first be enhanced:
 -   The column objects will gain a more structured base class, and will serve as
     providers for DOM references
 
--   The \'exec\' command will be able to run a rule, if the reference is correct
+-   The 'exec' command will be able to run a rule, if the reference is correct
 
 -   Taskwarrior will store state data in a new `state.data` file
 

docs/rfcs/sync.md

@@ -17,7 +17,7 @@ The algorithm used to achieve this is simple and effective, paralleling what SCM
 In this document, we adopt the convention discussed in Section 1.3.2 of
 [RFC1122](https://tools.ietf.org/html/rfc1122#page-16) of using the capitalized words MUST, REQUIRED, SHOULD, RECOMMENDED, MAY, and OPTIONAL to define the significance of each particular requirement specified in this document.
 
-In brief: \"MUST\" (or \"REQUIRED\") means that the item is an absolute requirement of the specification; \"SHOULD\" (or \"RECOMMENDED\") means there may exist valid reasons for ignoring this item, but the full implications should be understood before doing so; and \"MAY\" (or \"OPTIONAL\") means that this item is optional, and may be omitted without careful consideration.
+In brief: "MUST" (or "REQUIRED") means that the item is an absolute requirement of the specification; "SHOULD" (or "RECOMMENDED") means there may exist valid reasons for ignoring this item, but the full implications should be understood before doing so; and "MAY" (or "OPTIONAL") means that this item is optional, and may be omitted without careful consideration.
 
 
 ## Problem Definition

docs/rfcs/task.md

@@ -20,7 +20,7 @@ The data attributes are also subject to change.
 
 In this document, we adopt the convention discussed in Section 1.3.2 of [RFC1122](https://tools.ietf.org/html/rfc1122#page-16) of using the capitalized words MUST, REQUIRED, SHOULD, RECOMMENDED, MAY, and OPTIONAL to define the significance of each particular requirement specified in this document.
 
-In brief: \"MUST\" (or \"REQUIRED\") means that the item is an absolute requirement of the specification; \"SHOULD\" (or \"RECOMMENDED\") means there may exist valid reasons for ignoring this item, but the full implications should be understood before doing so; and \"MAY\" (or \"OPTIONAL\") means that this item is optional, and may be omitted without careful consideration.
+In brief: "MUST" (or "REQUIRED") means that the item is an absolute requirement of the specification; "SHOULD" (or "RECOMMENDED") means there may exist valid reasons for ignoring this item, but the full implications should be understood before doing so; and "MAY" (or "OPTIONAL") means that this item is optional, and may be omitted without careful consideration.
 
 
 ## General Format
@@ -33,7 +33,7 @@ The JSON looks like this:
 
 While this is not a valid task (there are missing fields), the format is illustrated.
 
-All attribute names are quoted with \" (U+0022).
+All attribute names are quoted with " (U+0022).
 A name will always have a corresponding value, and if a value is blank, then the name/value pair is omitted from the line.
 Newline characters are not permitted within the value, meaning that a task consists of a single line of text.
 
@@ -52,7 +52,7 @@ Strings may consist of any UTF8 encoded characters.
 
 ## Data Type: Fixed String
 
-A fixed string is one value from a set of acceptable values, such as a priority level, where the values may only be \"\", \"L\", \"M\" or \"H\".
+A fixed string is one value from a set of acceptable values, such as a priority level, where the values may only be "", "L", "M" or "H".
 
 
 ## Data Type: UUID
@@ -153,9 +153,9 @@ The supported units are:
 -   yr
 -   y
 
-Note that some values lack precision, for example \"2q\" means two quarters, or half a year.
+Note that some values lack precision, for example "2q" means two quarters, or half a year.
 
-Note that not all combinations of and make sense, for example \"3annual\" makes no sense, but evaluates to \"3years\".
+Note that not all combinations of and make sense, for example "3annual" makes no sense, but evaluates to "3years".
 
 
 ## The Attributes
@@ -227,15 +227,15 @@ At a minimum, a valid task contains:
 -   entry
 -   description
 
-*Deleted* - A deleted task MUST also have \"status\":\"deleted\", an \"end\" date and a \"modified\" date.
+*Deleted* - A deleted task MUST also have "status":"deleted", an "end" date and a "modified" date.
 
-*Completed* - A completed task MUST also have \"status\":\"completed\", an \"end\" date and a \"modified\" date.
+*Completed* - A completed task MUST also have "status":"completed", an "end" date and a "modified" date.
 
-*Waiting* - A waiting task MUST also have \"status\":\"waiting\" and a \"wait\" date.
+*Waiting* - A waiting task MUST also have "status":"waiting" and a "wait" date.
-The task is hidden from the user, until that \"wait\" date has passed, whereupon the status reverts to \"pending\", and the \"wait\" date is removed.
+The task is hidden from the user, until that "wait" date has passed, whereupon the status reverts to "pending", and the "wait" date is removed.
 
-*Recurring Parent* - When a recurring task is entered, it MUST have \"status\":\"recurring\", a \"recur\" period and a \"due\" date.
+*Recurring Parent* - When a recurring task is entered, it MUST have "status":"recurring", a "recur" period and a "due" date.
-It MAY also have an \"until\" date.
+It MAY also have an "until" date.
 Recurring parent tasks are hidden from the user.
 
 *Recurring Child* - A recurring child task is not created by the user, but is cloned from the recurring parent task by the Taskserver.
@@ -271,18 +271,18 @@ The status field describes the state of the task, which may ONLY be one of these
 A pending task is a task that has not yet been completed or deleted.
 This is the typical state for a task.
 
-A deleted task is one that has been removed from the pending state, and MUST have an \"end\" field specified.
+A deleted task is one that has been removed from the pending state, and MUST have an "end" field specified.
-Given the required \"entry\" and \"end\" field, it can be determined how long the task was pending.
+Given the required "entry" and "end" field, it can be determined how long the task was pending.
 
-A completed task is one that has been removed from the pending state by completion, and MUST have an \"end\" field specified.
+A completed task is one that has been removed from the pending state by completion, and MUST have an "end" field specified.
-Given the required \"entry\" and \"end\" fields, it can be determine how long the task was pending.
+Given the required "entry" and "end" fields, it can be determine how long the task was pending.
 
-A waiting task is ostensibly a pending task that has been hidden from typical view, and MUST have a \"wait\" field containing the date when the task is automatically returned to the pending state.
+A waiting task is ostensibly a pending task that has been hidden from typical view, and MUST have a "wait" field containing the date when the task is automatically returned to the pending state.
-If a client sees a task that is in the waiting state, and the \"wait\" field is earlier than the current date and time, the client MUST remove the \"wait\" field and set the \"status\" field to \"pending\".
+If a client sees a task that is in the waiting state, and the "wait" field is earlier than the current date and time, the client MUST remove the "wait" field and set the "status" field to "pending".
 
 A recurring task is essentially a parent template task from which child tasks are cloned.
-The parent remains hidden from view, and contains a \"mask\" field that represents the recurrences.
+The parent remains hidden from view, and contains a "mask" field that represents the recurrences.
-Each cloned child task has an \"imask\" field that indexes into the parent \"mask\" field, as well as a \"parent\" field that lists the UUID of the parent.
+Each cloned child task has an "imask" field that indexes into the parent "mask" field, as well as a "parent" field that lists the UUID of the parent.
 
 
 ## Attribute: uuid
@@ -294,66 +294,66 @@ UUID fields are permanent.
 
 ## Attribute: entry
 
-When a task is created, it MUST be assigned an \"entry\" date by the client.
+When a task is created, it MUST be assigned an "entry" date by the client.
 This is the creation date of the task.
 
 
 ## Attribute: description
 
-When a task is created, it MUST have a \"description\" field value, which contains UTF8 characters.
+When a task is created, it MUST have a "description" field value, which contains UTF8 characters.
-A \"description\" field may not contain newline characters, but may contain other characters, properly escaped.
+A "description" field may not contain newline characters, but may contain other characters, properly escaped.
 See <https://json.org> for details.
 
 
 ## Attribute: start
 
-To indicate that a task is being worked on, it MAY be assigned a \"start\" field.
+To indicate that a task is being worked on, it MAY be assigned a "start" field.
 Such a task is then considered Active.
 
 
 ## Attribute: end
 
-When a task is deleted or completed, is MUST be assigned an \"end\" field.
+When a task is deleted or completed, is MUST be assigned an "end" field.
-It is not valid for a task to have an \"end\" field unless the status is also \"completed\" or \"deleted\".
+It is not valid for a task to have an "end" field unless the status is also "completed" or "deleted".
-If a completed task is restored to the \"pending\" state, the \"end\" field is removed.
+If a completed task is restored to the "pending" state, the "end" field is removed.
 
 
 ## Attribute: due
 
-A task MAY have a \"due\" field, which indicates when the task should be completed.
+A task MAY have a "due" field, which indicates when the task should be completed.
 
 
 ## Attribute: until
 
-A recurring task MAY have an \"until\" field, which is the date after which no more recurring tasks should be generated.
+A recurring task MAY have an "until" field, which is the date after which no more recurring tasks should be generated.
-At that time, the parent recurring task is set to \"completed\".
+At that time, the parent recurring task is set to "completed".
 
 
 ## Attribute: wait
 
-A task MAY have a \"wait\" field date, in conjunction with a \"status\" of \"waiting\".
+A task MAY have a "wait" field date, in conjunction with a "status" of "waiting".
 A waiting task is one that is not typically shown on reports until it is past the wait date.
 
 An example of this is a birthday reminder.
-A task may be entered for a birthday reminder in 10 months time, but can have a \"wait\" date 9 months from now, which means the task remains hidden until 1 month before the due date.
+A task may be entered for a birthday reminder in 10 months time, but can have a "wait" date 9 months from now, which means the task remains hidden until 1 month before the due date.
 This prevents long-term tasks from cluttering reports until they become relevant.
 
 
 ## Attribute: recur
 
-The \"recur\" field is for recurring tasks, and specifies the period between child tasks, in the form of a duration value.
+The "recur" field is for recurring tasks, and specifies the period between child tasks, in the form of a duration value.
-The value is kept in the raw state (such as \"3wks\") as a string, so that it may be evaluated each time it is needed.
+The value is kept in the raw state (such as "3wks") as a string, so that it may be evaluated each time it is needed.
 
 
 ## Attribute: mask
 
-A parent recurring task has a \"mask\" field that is an array of child status indicators.
+A parent recurring task has a "mask" field that is an array of child status indicators.
 Suppose a task is created that is due every week for a month.
-The \"mask\" field will look like:
+The "mask" field will look like:
 
     "----"
 
-This mask has four slots, indicating that there are four child tasks, and each slot indicates, in this case, that the child tasks are pending (\"-\").
+This mask has four slots, indicating that there are four child tasks, and each slot indicates, in this case, that the child tasks are pending ("-").
 The possible slot indicators are:
 
 * `-` - Pending
@@ -374,24 +374,24 @@ This would indicate that the second task is pending, the first and third are com
 
 ## Attribute: imask
 
-Child recurring tasks have an \"imask\" field instead of a \"mask\" field like their parent.
+Child recurring tasks have an "imask" field instead of a "mask" field like their parent.
-The \"imask\" field is a zero-based integer offset into the \"mask\" field of the parent.
+The "imask" field is a zero-based integer offset into the "mask" field of the parent.
 
-If a child task is completed, one of the changes that MUST occur is to look up the parent task, and using \"imask\" set the \"mask\" of the parent to the correct indicator.
+If a child task is completed, one of the changes that MUST occur is to look up the parent task, and using "imask" set the "mask" of the parent to the correct indicator.
 This prevents recurring tasks from being generated twice.
 
 
 ## Attribute: parent
 
-A recurring task instance MUST have a \"parent\" field, which is the UUID of the task that has \"status\" of \"recurring\".
+A recurring task instance MUST have a "parent" field, which is the UUID of the task that has "status" of "recurring".
-This linkage between tasks, established using \"parent\", \"mask\" and \"imask\" is used to track the need to generate more recurring tasks.
+This linkage between tasks, established using "parent", "mask" and "imask" is used to track the need to generate more recurring tasks.
 
 
 ## Attribute: annotation\_\...
 
 Annotations are strings with timestamps.
-Each annotation itself has an \"entry\" field and a \"description\" field, similar to the task itself.
+Each annotation itself has an "entry" field and a "description" field, similar to the task itself.
-Annotations form an array named \"annotations\".
+Annotations form an array named "annotations".
 For example (lines broken for clarity):
 
     "annotations":[
@@ -407,17 +407,17 @@ For example:
 
     "project":"Personal Taxes"
 
-Note that projects receive special handling, so that when a \".\" (U+002E) is used, it implies a hierarchy, which means the following two projects:
+Note that projects receive special handling, so that when a "." (U+002E) is used, it implies a hierarchy, which means the following two projects:
 
     "Home.Kitchen"
     "Home.Garden"
 
-are both considered part of the \"Home\" project.
+are both considered part of the "Home" project.
 
 
 ## Attribute: tags
 
-The \"tags\" field is an array of string, where each string is a single word containing no spaces.
+The "tags" field is an array of string, where each string is a single word containing no spaces.
 For example:
 
     "tags":["home","garden"]
@@ -425,7 +425,7 @@ For example:
 
 ## Attribute: priority
 
-The \"priority\" field, if present, MAY contain one of the following strings:
+The "priority" field, if present, MAY contain one of the following strings:
 
     "priority":"H"
     "priority":"M"
@@ -437,26 +437,26 @@ An absent priority field indicates no priority.
 
 ## Attribute: depends
 
-The \"depends\" field is a string containing a comma-separated unique set of UUIDs.
+The "depends" field is a string containing a comma-separated unique set of UUIDs.
 If task 2 depends on task 1, then it is task 1 that must be completed first.
-Task 1 is considered a \"blocking\" tasks, and task 2 is considered a \"blocked\" task.
+Task 1 is considered a "blocking" tasks, and task 2 is considered a "blocked" task.
 For example:
 
     "depends":",, ..."
 
-Note that in a future version of this specification, this will be changed to a JSON array of strings, like the \"tags\" field.
+Note that in a future version of this specification, this will be changed to a JSON array of strings, like the "tags" field.
 
 
 ## Attribute: modified
 
-A task MUST have a \"modified\" field set if it is modified.
+A task MUST have a "modified" field set if it is modified.
-This field is of type \"date\", and is used as a reference when merging tasks.
+This field is of type "date", and is used as a reference when merging tasks.
 
 
 ## Attribute: scheduled
 
-A task MAY have a \"scheduled\" field, which indicates when the task should be available to start.
+A task MAY have a "scheduled" field, which indicates when the task should be available to start.
-A task that has passed its \"scheduled\" data is said to be \"ready\".
+A task that has passed its "scheduled" data is said to be "ready".
 
 
 ## User Defined Attributes

docs/rfcs/workweek.md

@@ -14,7 +14,7 @@ Taskwarrior supports the idea that a week starts on either a Sunday or a Monday,
 This was added eight years ago, simply for display purposes in the `calendar` report.
 Since then its use has propagated and it influences the `sow` date reference.0
 
-Further requests have been made to make this more flexible, so that the notion of \'weekend\' can be defined.
+Further requests have been made to make this more flexible, so that the notion of 'weekend' can be defined.
 Furthermore, the idea that every week has a weekend has also been questioned.
 
 It has become clear that a `weekstart` setting, and the notion of a weekend are no longer useful.