Differences

This shows you the differences between two versions of the page.

--- contributing [2015/08/05 16:32] – remove errant newline gmcharlton
+++ contributing [2017/02/28 15:32] – [Offering support] rjs7
@@ Line 30: / Line 30: @@
 When problems are reported on the [[https://bugs.launchpad.net/evergreen|Evergreen]] and [[https://bugs.launchpad.net/opensrf|OpenSRF]] Launchpad instances, or requests for help are posted to the [[http://evergreen-ils.org/listserv.php|mailing lists]], a positive response is a sign of a great community. Please try to remember that to reach the point of reporting a bug or asking for help, the person posting the bug is probably quite frustrated and some of that frustration might be evident in their language; focus on the technical problems underlying the bug report or help request and don't take any comments about the project personally. Keep in mind that your responses will be visible on the mailing list archives and in the bug database for perpetuity and represent one of the public faces of the Evergreen project: be nice!
+===== Translating Evergreen =====
+To learn how you can help translate Evergreen into your language, see [[eg_translations|Evergreen translations]].
 ===== Documentation Contribution =====
@@ Line 159: / Line 163: @@
   * New features should be accompanied by a file in the repository under the docs/RELEASE_NOTES_NEXT/ directory.  The file should be in asciidoc format and contain enough description to enable the documentation team to write something coherent about the new functionality.  The name of the file should match the feature.  No numbering, etc. is required.  With each release, the contents of this directory will be appended to the release notes. [[contributing:release_notes|See Tips for Writing Release Notes]]
   * Bug fix patches should explain how to test the bug fix in the commit message.
-  * Test your code; our project is deployed in many different environment and we don't want a bug fix or new feature for your environment to break when deployed in a different environment. If possible, include unit tests in your contribution to demonstrate that the code does what is supposed to, and to help prevent others from breaking your code in the future.
+  * Test your code; our project is deployed in many different environments and we don't want a bug fix or new feature for your environment to break when deployed in a different environment. If possible, include unit tests in your contribution to demonstrate that the code does what is supposed to, and to help prevent others from breaking your code in the future.
   * If it is a performance enhancement, please provide confirming test results to show the benefit of your changes. You can post changes without this information, though changes will not be applied until somebody has tested the code and found a significant performance improvement.