[royale-docs] branch master updated: Update README.md

[an...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

andreww pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/royale-docs.git


The following commit(s) were added to refs/heads/master by this push:
     new 831457c  Update README.md
831457c is described below

commit 831457caf3d594384b152f7352cb47ce6da60fa4
Author: Andrew Wetmore <an...@cottage14.com>
AuthorDate: Sun Dec 22 07:30:45 2019 -0400

    Update README.md
    
    Small text changes
---
 README.md | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/README.md b/README.md
index a9442a5..a20ad89 100644
--- a/README.md
+++ b/README.md
@@ -36,7 +36,7 @@ Each `.md` page starts with "front matter" structured like this:
 layout: docpage
 title: README
 description: short description of the page that will help social networks to show appropiate info
-premalink: /friendly-url
+permalink: /friendly-url
 ---
 
 ```
@@ -46,16 +46,17 @@ Use HTML comments at the top of the document for any explanatory notes for the d
 ## File names and titles
 
 * File names do not have to be the same as the titles that display at the top of the file.
-* For file names, use all lower-case, join words with - and not _ or `%20` statements, and add the markdown specification. The file name should be `another-important-thing.md`, not `Another%20Important%20Thing.md`, `AnotherImportantThing.md`, or `Another_important_thing.md`. This is important for SEO, human readability, and readability by assistive devices.
-* Remember to add a permalink. For the latest example it should be: `permalink: /another-important-thing`, if is nested the permalink will be prefixed with the required folder estrucrure.
-* File titles should be in sentence case: "Another important Royale thing", not "Another Important Royale Thing". The point here is that the more capitals involved, the harder it is to read the statement.
+* For file names, use all lower-case, join words with - and not _ or `%20` statements, and add the markdown specification. The file name should be `another-important-thing.md`, not `Another%20Important%20Thing.md`, `AnotherImportantThing.md`, or `Another_important_thing.md`. These details are important for SEO, human readability, and readability by assistive devices.
+* Remember to add a permalink. For the latest example it should be: `permalink: /another-important-thing`. If the file is `working-with-widgets.md` in the `widgets` folder, its permalink would be `widgets/working-with-widgets`.
+* File titles should be in sentence case: "Another important Royale thing", not "Another Important Royale Thing". The more capital letters involved, the harder it is to read the statement.
 
 ## Documentation conventions
 
 1. Address the reader directly, and in active voice, so "To do X, follow these steps..." rather than "When a developer wishes to do X, these steps would be followed..."
-2. Instead of "he or she" use "they" when the pronoun is for an indefinite singular actor: "When someone has an existing application to migrate, they should start by...". This offends my grammarian soul, but is becoming standard English.
-3. Link generously to other content in the help docs that may throw light on the current subject.
-4. When writing how-to material, provide the *what*, the *so what*, and the *now what*: what a widget is, why widgets can be important in your code, and here's how to find, adapt, or create the widget of your dreams.
+2. Do not insert yourself into the material with comments like "I used to do X in Flex, but I find it easier in Royale to do y..." Keep the focus on the reader.
+3. Instead of "he or she" use "they" when the pronoun is for an indefinite singular actor: "When someone has an existing application to migrate, they should start by...". This offends my grammarian soul, but is becoming standard English.
+4. Link generously to other content in the help docs that may throw light on the current subject.
+5. When writing how-to material, provide the *what*, the *so what*, and the *now what*: what a widget is, why widgets can be important in your code, and here's how to find, adapt, or create the widget of your dreams.
 
 ## Links