From c3d1ba2fe4f17618a89e60dd31b1c984c53061fa Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Pa=C5=ADlo=20Ebermann?= Date: Fri, 9 Jun 2017 20:46:17 +0200 Subject: [PATCH] =?UTF-8?q?markdown=20formatting=20fix=20=E2=80=93=20finis?= =?UTF-8?q?h=20bold=20span.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- DEVELOPMENT.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/DEVELOPMENT.md b/DEVELOPMENT.md index 36a06b8029..84e3b5a853 100644 --- a/DEVELOPMENT.md +++ b/DEVELOPMENT.md @@ -38,7 +38,7 @@ For each change in the specification we should _always_ consider the following: - Tooling. Strive to support code generation, software interfaces, and spec generation techniques. Some features may be impossible to support in different frameworks/languages. These should be documented and considered during the change approval process. - Visualization. Can the specification change be graphically visualized somehow in a UI or other interface? -Spec changes should be approved by a majority of the committers. Approval can be given by commenting on the issue itself, for example, "Approved by @fehguy". After voting criteria is met, any committer can merge the PR. (**TODO: we will want to formalize what voting criteria actually is). +Spec changes should be approved by a majority of the committers. Approval can be given by commenting on the issue itself, for example, "Approved by @fehguy". After voting criteria is met, any committer can merge the PR. (**TODO**: we will want to formalize what voting criteria actually is). No change should be approved until there is documentation for it, supplied in an accompanying PR.