Commit be56b032 authored by Sarah Fowler's avatar Sarah Fowler

Merge branch 'typographical_fixes' into 'master'

Typographical fixes

See merge request !27
parents 737fcdd8 7d3e6b5c
......@@ -28,7 +28,7 @@ modifying the Ethereum Improvement Process to be a descriptive rather than a
prescriptive social institution. Unlike Ethereum, Tezos already has a
prescriptive decentralized governance institution: The quorum of Tezos bakers
and delegates. The goal of this proposal is to support that institution by
encouraging high quality technical discussion, documentation and, where
encouraging high-quality technical discussion, documentation and, where
appropriate, non-binding standardization.
## What is a TZIP?
......@@ -53,7 +53,7 @@ Each TZIP has both authors and advocates, who may be (but are not required to
be) the same individuals. Whereas the *TZIP author* is responsible for
generating the proposal and any necessary accompanying materials, the *TZIP
advocate* is responsible for communicating the proposal to the community and
maintaing the TZIP FAQ. Healthy proposals should have multiple independent
maintaining the TZIP FAQ. Healthy proposals should have multiple independent
advocates and a robust accompanying FAQ.
## TZIP Rationale
......@@ -89,19 +89,18 @@ does.
A TZIP must meet certain minimum criteria, which may change depending on the
TZIP type. Some TZIP types may require an attached reference implementation of
the proposed improvement. Other TZIP types may require two independent
implementations. If so, the associated software should be be of minimal possible
implementations. If so, the associated software should be of minimal possible
complexity and be focused primarily on illustrating the contents of the single
proposal to which it is attached. Reference implementations should show evidence
of correctness, ideally via formal methods, but at minimum via comprehensive
testing.
## TZIP Roles and Responsibilities:
Parties involved in the process are the:
- *TZIP authors* write proposals and accompanying materials and request TZIP
status changes. In the case of multiple authors, the a single author will be
status changes. In the case of multiple authors, a single author will be
designated as primary.
- *TZIP advocates* endorse proposals, seek community feedback and maintain the
......@@ -129,7 +128,7 @@ expressed interest in serving as TZIP Editor:
For each submitted TZIP, the editors will select one or more editors to assume
responsibility for the proposal. This editor or editors will:
- Read the TZIP to check if complies with all relevant standards articulated in
- Read the TZIP to check if it complies with all relevant standards articulated in
this document and elsewhere, both global TZIP standards and those particular
to the TZIP type.
......@@ -146,7 +145,7 @@ If the TZIP does not meet the standards at each of these stages, the editors
will send it back to the author for revision, with specific instructions. This
process may repeat as many times as necessary. The editors may additionally
refer the TZIP to outside reviewers with relevant knowledge. Editors may also
outright reject an TZIP submission which is unsuitable for review, or is
outright reject a TZIP submission, which is unsuitable for review or is
otherwise non-compliant with the standards outlined in relevant active TZIPs.
Should the editors approve the TZIP, they will:
......@@ -159,7 +158,7 @@ Should the editors approve the TZIP, they will:
- Coordinate any further steps with the TZIP authors and advocates, as required
by the specific TZIP type.
The editors will at all stages of the TZIP process render fair and
The editors will, at all stages of the TZIP process, render fair and
impartial judgement. An editor cannot review a TZIP of which they are an
advocate or an author.
......@@ -314,9 +313,9 @@ Each TZIP should have the following parts:
given status “Last Call”, but it need not be completed before the TZIP is
merged as draft.
- Copyright Waiver - All TZIPs must be in the public domain, or a under a
- Copyright Waiver - All TZIPs must be in the public domain, or under a
permissive license substantially identical to placement in the public
domain.See the bottom of this TZIP for an example copyright waiver.
domain. See the bottom of this TZIP for an example copyright waiver.
## TZIP Formats and Templates
......@@ -401,7 +400,7 @@ headers should be in `yyyy-mm-dd` format, e.g. 2001-08-14.
#### `updated` header
The `updated` header records the date(s) when the TZIP was updated with
"substantional" changes. This header is only valid for TZIPs of Draft and Active
"substantial" changes. This header is only valid for TZIPs of Draft and Active
status.
#### `requires` header
......@@ -458,8 +457,6 @@ Copyright and related rights waived via
[Liquidity]: http://www.liquidity-lang.org/
[Fi]: https://learn.fi-code.com/
[Markdown]: https://docs.gitlab.com/ee/user/markdown.html
[TZIP-0002]: /Proposals/TZIP-0002/TZIP-0002.md
[TZIP-0003]: /Proposals/TZIP-0003/TZIP-0003.md
[tip-1]: https://gitlab.com/tips2/TIPs/blob/master/TIPS/tip-1.md
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment