summaryrefslogtreecommitdiff
path: root/CONTRIBUTING.md
diff options
context:
space:
mode:
authorTim Kientzle <kientzle@acm.org>2015-04-18 18:14:17 -0700
committerTim Kientzle <kientzle@acm.org>2015-04-18 18:14:17 -0700
commitff86dd102fe1378e4d028998246f16d6d1631c9e (patch)
treed61a5b424e473ff384c3e5c0dda5f8281b128e6a /CONTRIBUTING.md
parentd41eed94c20f2315d93644b1df08b0b82c6184da (diff)
downloadlibarchive-ff86dd102fe1378e4d028998246f16d6d1631c9e.tar.gz
More wording changes
Diffstat (limited to 'CONTRIBUTING.md')
-rw-r--r--CONTRIBUTING.md20
1 files changed, 13 insertions, 7 deletions
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index f20fafea..9ccc45c3 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -16,14 +16,14 @@ Basic Information
What compiler and/or IDE you are using (include version):
If you are using a pre-packaged binary
- Exact package name and version: (for example, libarchive13-3.1.2-11)
+ Exact package name and version:
Repository you obtained it from:
Description of the problem you are seeing:
What did you do?
What did you expect to happen?
- What actually happen?
- What log files or erorr messages were produced?
+ What actually happened?
+ What log files or error messages were produced?
How the libarchive developers can reproduce your problem:
What other software was involved?
@@ -31,6 +31,8 @@ How the libarchive developers can reproduce your problem:
How can we obtain any of the above?
```
+Depending on the specific type of issue, other information will be helpful:
+
## Test Failures
If you see any test failures, please include the information above and also:
@@ -53,14 +55,18 @@ If you are trying to write a program using libarchive, please include the inform
## Libarchive produced incorrect output
+Please tell us what program you ran, any command-line arguments you provided, and details of the input files (`ls -l` output is helpful here). If the problem involved a command-line program, please copy the full terminal text into the report, including the command line and any error messages.
+
Please try to make the output file available to us. Unless it is very large, you can upload it into a fresh github repository and provide a link in your issue report.
-## Libarchive failed to read a particular input file
+## Libarchive could not read a particular input file
Note: If you can provide a **very small** input file that reproduces the problem, we can add that to our test suite. This will ensure that the bug does not reappear in the future.
-If the input file is large and/or proprietary, please post an issue first, then follow-up with an email to libarchive-discuss@googlegroups.com so one of the libarchive developers can follow up with you. In your email, please include a link to the issue report.
+A link to the relevant file is usually sufficient.
+
+If you cannot provide the input file or a link to the file, please let us know if there is some other way to obtain it.
## Documentation improvements
@@ -78,11 +84,11 @@ We are always interested in improving the libarchive documentation. Please tell
We welcome all code submissions. But of course, some code submissions are easier for us to respond to than others. The best code submissions:
-* Address a single issue. There have been many cases where a simple fix to an obvious problem did not get handled for months because the patch that was provided also included an unrelated change affecting a controversial area of the code.
+* Address a single issue. There have been many cases where a simple fix to an obvious problem did not get handled for months because the patch that was provided also included an unrelated change affecting an especially complex area of the code.
* Follow existing libarchive code style and conventions. Libarchive generally follows [BSD KNF](https://www.freebsd.org/cgi/man.cgi?query=style&sektion=9) for formatting code.
-* Do not make gratuitous changes to existing whitespace, capitalization, or spelling.
+* Do not make unnecessary changes to existing whitespace, capitalization, or spelling.
* Include detailed instructions for reproducing the problem you're fixing. We do try to verify that a submission actually fixes a real problem. If we can't reproduce the problem, it will take us longer to evaluate the fix. For this reason, we encourage you to file an issue report first with details on reproducing the problem, then refer to that issue in your pull request.