]> git.madduck.net Git - etc/vim.git/blobdiff - docs/contributing/issue_triage.md

madduck's git repository

Every one of the projects in this repository is available at the canonical URL git://git.madduck.net/madduck/pub/<projectpath> — see each project's metadata for the exact URL.

All patches and comments are welcome. Please squash your changes to logical commits before using git-format-patch and git-send-email to patches@git.madduck.net. If you'd read over the Git project's submission guidelines and adhered to them, I'd be especially grateful.

SSH access, as well as push access can be individually arranged.

If you use my repositories frequently, consider adding the following snippet to ~/.gitconfig and using the third clone URL listed for each project:

[url "git://git.madduck.net/madduck/"]
  insteadOf = madduck:

projects / etc / vim.git / blobdiff
? search:
summary | shortlog | log | commit | commitdiff | tree
raw | inline | side by side
Rewrite mostly useless assert in test_trans.py (#3810)
[etc/vim.git] / docs / contributing / issue_triage.md
diff --git a/docs/contributing/issue_triage.md b/docs/contributing/issue_triage.md
index 9b987fb24250cad9bdcfbb9509c198bf8c76a5cf..89cfff76f7fd1bc20e9a05c4d672cd9891e532eb 100644 (file)
--- a/docs/contributing/issue_triage.md
+++ b/docs/contributing/issue_triage.md
@@ -1,6 +1,6 @@
 # Issue triage
 
-Currently, _Black_ uses the issue tracker for bugs, feature requests, proposed design
+Currently, _Black_ uses the issue tracker for bugs, feature requests, proposed style
 modifications, and general user support. Each of these issues have to be triaged so they
 can be eventually be resolved somehow. This document outlines the triaging process and
 also the current guidelines and recommendations.
@@ -42,7 +42,7 @@ The lifecycle of a bug report or user support issue typically goes something lik
 1. _the issue is waiting for triage_
 2. **identified** - has been marked with a type label and other relevant labels, more
    details or a functional reproduction may be still needed (and therefore should be
-   marked with `S: needs repro` or `S: awaiting reponse`)
+   marked with `S: needs repro` or `S: awaiting response`)
 3. **confirmed** - the issue can reproduced and necessary details have been provided
 4. **discussion** - initial triage has been done and now the general details on how the
    issue should be best resolved are being hashed out
@@ -53,13 +53,13 @@ The lifecycle of a bug report or user support issue typically goes something lik
    - the issue has been fixed
    - duplicate of another pre-existing issue or is invalid
 
-For enhancement, documentation, and design issues, the lifecycle looks very similar but
+For enhancement, documentation, and style issues, the lifecycle looks very similar but
 the details are different:
 
 1. _the issue is waiting for triage_
 2. **identified** - has been marked with a type label and other relevant labels
 3. **discussion** - the merits of the suggested changes are currently being discussed, a
-   PR would be acceptable but would be at sigificant risk of being rejected
+   PR would be acceptable but would be at significant risk of being rejected
 4. **accepted & awaiting PR** - it's been determined the suggested changes are OK and a
    PR would be welcomed (`S: accepted`)
 5. **closed**: - the issue has been resolved, reasons include:
vim configuration

Legalese

All content available in this repository is copyright © martin f. krafft, unless otherwise noted.

All files and their content are released under the terms of the Artistic Licence 2.0, unless otherwise noted.

The operator of this repository shall not be held liable for offending content in pages linking to or linked from these page, nor does he endorse their content unless stated otherwise.