aboutsummaryrefslogtreecommitdiffstats
path: root/doc/contribute.rst
diff options
context:
space:
mode:
authorgritbub <38131016+gritbub@users.noreply.github.com>2018-05-18 17:26:51 -0500
committergritbub <38131016+gritbub@users.noreply.github.com>2018-06-01 14:18:09 -0500
commit8122c18944b69305060b03fad5b5a46ca59c0975 (patch)
tree5bd329ebfcdc411b35372fba2873269acea2c1d7 /doc/contribute.rst
parente135fe7fbe1a79256f6f4ab2c5a5cd1666166197 (diff)
downloadghdl-8122c18944b69305060b03fad5b5a46ca59c0975.tar.gz
ghdl-8122c18944b69305060b03fad5b5a46ca59c0975.tar.bz2
ghdl-8122c18944b69305060b03fad5b5a46ca59c0975.zip
Rephrase documentation - typos, grammatical nuance, and links
Diffstat (limited to 'doc/contribute.rst')
-rw-r--r--doc/contribute.rst30
1 files changed, 15 insertions, 15 deletions
diff --git a/doc/contribute.rst b/doc/contribute.rst
index cf1ca7c2a..7886b538a 100644
--- a/doc/contribute.rst
+++ b/doc/contribute.rst
@@ -4,16 +4,16 @@
Contributing
############
-The first step might be to use GHDL and explore it's possibilities in an own project. If you are new to VHDL, see the
+The first step might be to use GHDL and explore its possibilities in your own project. If you are new to VHDL, see the
:ref:`USING:QuickStart` for an introduction. Furthermore, we encourage you to read :ref:`USING:Invoking`, where the most
commonly used options are explained. You can also check the complete :ref:`REF:Command`.
-If you are more familiar with GHDL, you might start asking yourself how it works internally. Then, you might find
+If you are more familiar with GHDL, you might start asking yourself how it works internally. If so, you might find
:ref:`Implementation of VHDL <REF:ImplVHDL>` and :ref:`Implementation of VITAL <REF:ImplVITAL>` interesting.
-While using GHDL, you might find flaws, such as bugs, missing features, typos in the documentation or topics which are
-still not covered. In order to improve GHDL, we welcome bug reports, suggestions and contributions for any aspect of
-GHDL. Either if it's a bug or an enhancement, have a look at the |SHIELD:issues-open| and |SHIELD:issues-closed| to see
+While using GHDL, you might find flaws, such as bugs, missing features, typos in the documentation, or topics which still are
+not covered. In order to improve GHDL, we welcome bug reports, suggestions, and contributions for any aspect of
+GHDL. Whether it's a bug or an enhancement, have a look at the |SHIELD:issues-open| and |SHIELD:issues-closed| to see
if someone already told us about it. You might find a solution there.
If you found no information on your topic, please, report so that we are aware! You can reach us through various ways:
@@ -34,31 +34,31 @@ Reporting bugs
* If the compiler crashes, this is a bug. Reliable tools never crash.
* If the compiler emits an error message for a perfectly valid input or does not emit an error message for an invalid input, this may be a bug.
* If the executable created from your VHDL sources crashes, this may be a bug at runtime or the code itself may be wrong. However, since VHDL has a notion of pointers, an erroneous VHDL program (using invalid pointers for example) may crash.
- * If a compiler message is not clear enough, please tell us. The error messages can be improved, but we have not enough experience with them.
+ * If a compiler message is not clear enough, please tell us. The error messages can be improved, but we do not have enough experience with them.
Please, report issues of this kind through |SHIELD:bug-report|, as this allows us to categorize issues into groups and
-assign developers to them. You can track the issue’s state and see how it’s getting solved.
+to assign developers to them. You can track the issue’s state and see how it’s getting solved.
.. IMPORTANT::
- To make it easier, please elaborate a `Minimum (non) Working Example` (`MWE <https://en.wikipedia.org/wiki/Minimal_Working_Example>`_) prior to sending the report, so that the possible bug source is isolated. Shall the MWE compile and run, it is a good idea to make it look like a test and make an assert statement should finish the execution; the severity level `note` indicates success, while a severity level `failure` indicates failure.
+ To make it easier, please elaborate a `Minimum (non) Working Example` (`MWE <https://en.wikipedia.org/wiki/Minimal_Working_Example>`_) prior to sending the report, so that the possible bug source is isolated. Should the MWE compile and run, it would be a good idea to make it look like a test and to make an assert statement that will stop execution; a severity level `note` indicates success, while a severity level `failure` indicates failure.
- Then, please include enough information for the maintainers to reproduce the problem. This includes:
+ Also, please include enough information for the maintainers to reproduce the problem. This includes:
* Operating system and version of GHDL (you can get it with :samp:`ghdl --version`).
- * Whether you have built GHDL from sources (provide short SHA of the used commit) or used the binary distribution (tell which release/tag).
+ * Whether you have built GHDL from sources (provide short SHA of the used commit) or used the binary distribution (note which release/tag).
* If you cannot compile, please report which compiler you are using and the version.
- * Content of the input files which make the MWE
+ * Content of the input files which comprise the MWE
* Description of the problem:
* Comment explaining whether the MWE should compile or not; if yes, whether or not is should run until the assertion.
- * What you expected to happen and what you actually get. If you know the LRM well enough, please specify the paragraph which might be not well implemented.
+ * What you expect to happen and what you actually get. If you know the LRM well enough, please specify which paragraph might not be implemented well.
* Samples of any log.
* Anything else that you think would be helpful.
.. NOTE::
- If you don't know the LRM, be aware that an issue claimed as bug report may be rejected because there is no bug according to it. GHDL aims at implementing VHDL as defined in `IEEE 1076 <http://ieeexplore.ieee.org/document/4772740/>`_. However, some other tools allow constructs which do not fully follow the standard revisions. Therefore, comparisons with other VHDL is not a solid argument. Some of them are supported by GHDL (see :ref:`IEEE_library_pitfalls`), but any such enhancement will have very low priority.
+ If you don't know the LRM, be aware that an issue claimed as a bug report may be rejected because there is no bug according to it. GHDL aims at implementing VHDL as defined in `IEEE 1076 <http://ieeexplore.ieee.org/document/4772740/>`_. However, some other tools allow constructs which do not fully follow the standard revisions. Therefore, comparisons with other VHDL is not a solid argument. Some of them are supported by GHDL (see :ref:`IEEE_library_pitfalls`), but any such enhancement will have very low priority.
.. _requesting_enhancements:
@@ -75,7 +75,7 @@ Improving the documentation
If you found a mistake in the documentation, please send a comment. If you didn't understand some parts of this manual,
please tell us. English is not our mother tongue, so this documentation may not be well-written.
-Likewise, rewriting part of the documentation or missing content (such as, examples) is a good way to improve it. Since
+Likewise, rewriting part of the documentation or missing content (such as examples) is a good way to improve it. Since
it automatically is built from `reStructuredText` and `Markdown` sources, you can fork, modify and request the
maintainers to pull your copy. See :ref:`pull_request`.
@@ -94,7 +94,7 @@ write access to our repositories, the project is hosted at GitHub, which follows
1. Make a copy (`fork <https://help.github.com/articles/fork-a-repo/>`_) of the project.
2. Do the changes you wish (edit, add, rename, move and/or delete).
-3. When you think that the changes are ready to be merged, you notify the maintainers by opening a `Pull Request <https://help.github.com/articles/creating-a-pull-request/>`_ (PR).
+3. When you think that the changes are ready to be merged, notify the maintainers by opening a `Pull Request <https://help.github.com/articles/creating-a-pull-request/>`_ (PR).
4. The maintainers will review the proposed changes and will reply in the corresponding thread if any further modification is required. If so, you can keep adding commits to the same branch, and the PR will be automatically updated.
5. Last, the maintainers will merge your branch. You will be notified, the PR will be closed, and you'll be allowed to delete the branch, if you want.