Various fixes and typos.

Author: Crell

bylaws/001-mission-and-structure.md

@@ -93,7 +93,7 @@ Multiple other Core Committee members may also be on the working group if they w
 
 A Limited Working Group consists of an Editor and at least two other individuals.  No Sponsor is required.  Any individual may be the Editor or member of a Limited Working Group, with the exception that the Editor may not also be a Secretary.
 
-### Working Group management
+### Working Group Management
 
 Working Groups are created by an Entrance Vote of the Core Committee.  The Entrance Vote includes the appointment of an Editor and, if applicable, the Sponsor.
 
@@ -109,7 +109,7 @@ The Secretaries will ensure that the Working Group is provided with necessary re
 
 ## Maintainers
 
-The Core Committee is ultimately responsible for all artifacts produced by the PHP FIG.  However, in the case of artifacts that are intended to change over time the Core Committee may delegate that responsibility to a Maintainer for one or more related artifacts.
+The Core Committee is ultimately responsible for all artifacts produced by the PHP FIG.  However, in the case of artifacts that are intended to change over time, the Core Committee may delegate that responsibility to a Maintainer for one or more related artifacts.
 
 Evolving artifacts follow Semantic Versioning.  If it is unclear if a given change would qualify as a bugfix vs a minor release, the Maintainer will assume minor release.
 
@@ -119,7 +119,7 @@ Evolving artifacts follow Semantic Versioning.  If it is unclear if a given chan
 
 The Editor of a Working Group is automatically the Maintainer of that Working Group's effort and output.
 
-The Maintainer of a given artifact is appointed by the Core Committee by Approval Vote.  Once a given artifact is created, the Maintainer may step down and name a replacement Maintainer at any time ith Implicit Approval.  If necessary, a Decision vote to appoint a new Maintainer may be held following a suitable nomination period.
+The Maintainer of a given artifact is appointed by the Core Committee by Approval Vote.  Once a given artifact is created, the Maintainer may step down and name a replacement Maintainer at any time with Implicit Approval.  If necessary, a Decision vote to appoint a new Maintainer may be held following a suitable nomination period.
 
 The Secretaries will ensure that the Maintainer has the necessary access and resources to develop the artifact, such as access to a GitHub repository, mailing list, chat room, or similar such tools.
 

bylaws/002-psr-workflow.md

@@ -44,7 +44,7 @@ If the Acceptance Vote passes, then the proposal officially becomes an accepted
 
 ## Erratas
 
-If an incongruence or the need for clarifications arise after the PSR acceptance, it is still possible to amend the document with an errata. The editor of the PSR has the power to handle those situations, but any meaningful change has to go through an Errata vote before merging. Typos and any other edits that do not change the meaning of the text do not fall in this category, and can be merged by the Secretaries at will.
+If an incongruence or the need for clarifications arise after the PSR acceptance, it is still possible to amend the document with an errata. The Maintainer of the PSR has the power to handle those situations, but any meaningful change has to go through an Errata vote before merging. Typos and any other edits that do not change the meaning of the text do not fall in this category, and can be merged by the Secretaries at will.
 
 Errata clarifications may only be added to the meta document, not to the spec itself, as items in their own section.  The spec itself may only be minimally edited to point readers toward a relevant errata if appropriate.
 

bylaws/003-votes.md

@@ -41,7 +41,7 @@ A Readiness Vote is called by the Editor of a proposed PSR in Draft Phase. Only
 
 ## Acceptance Vote
 
-An Approval Vote is called by the Sponsor of a proposed PSR in the Review Phase. It follows Approval Vote procedures.
+An Acceptance Vote is called by the Sponsor of a proposed PSR in the Review Phase. It follows Approval Vote procedures.
 
 ## Errata Vote
 

bylaws/009-per-workflow.md

@@ -2,7 +2,7 @@
 
 ## Formation
 
-The goal of the Pre-Draft stage is to determine whether a majority of the PHP FIG is interested in establishing a PER Working Group for a proposed concept.
+The goal of the Formation stage is to determine whether a majority of the PHP FIG is interested in establishing a PER Working Group for a proposed concept.
 
 Interested parties may discuss a possible proposal, including possible implementations, by whatever means they feel is appropriate. That includes informal discussion on official FIG discussion mediums of whether or not the idea has merit and is within the scope of the PHP FIG's goals.