]> 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
Fix merging implicit multiline strings that have inline comments (#3956)
[etc/vim.git] / docs / contributing / issue_triage.md
diff --git a/docs/contributing/issue_triage.md b/docs/contributing/issue_triage.md
index 865a47935ed7fe0d97ed3a23bcb8f5aa3f8e90cc..89cfff76f7fd1bc20e9a05c4d672cd9891e532eb 100644 (file)
--- a/docs/contributing/issue_triage.md
+++ b/docs/contributing/issue_triage.md
@@ -1,6 +1,6 @@
 # Issue triage
 
 # 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.
 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.
@@ -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
 
    - 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
 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:
 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.