Some more minor spelling improvements, some grammar improvement might be

good in some places as well.

Originally committed as revision 9424 to svn://svn.ffmpeg.org/ffmpeg/trunk

doc/issue_tracker.txt

 ffmpegs bug/patch/feature request tracker manual
 ================================================
 
-NOTE, this is a draft, its not yet recommended to send real bugreports to the
-tracker but rather use the mailing lists
-though, if you are brave and don't mind that your bugreport might disappear or
+NOTE, this is a draft, it is not yet recommended to send real bugreports to the
+tracker but rather use the mailing lists.
+Though, if you are brave and do not mind that your bugreport might disappear or
 that you might be mailbombed due to a misconfiguration, you can surely try
-to enter a real bugreport
+to enter a real bugreport.
 
 Overview:
 ---------
 FFmpeg uses roundup for tracking issues, new issues and changes to
 existing issues can be done through a web interface and through email.
-Its possible to subscribe to individual issues by adding yourself to the
+It is possible to subscribe to individual issues by adding yourself to the
 nosy list or to subscribe to the ffmpeg-issues mailing list which receives
 a mail for every change to every issue. Replies to such mails will also
 properly be added to the respective issue.
@@ -28,8 +28,8 @@ bug
 feature request
     Request of support for encoding or decoding of a new codec, container
     or variant.
-    Request of support for more, less or plain different output or behavior.
-    Where the current behavior cannot be considered wrong.
+    Request of support for more, less or plain different output or behavior
+    where the current behavior cannot be considered wrong.
 
 patch
     A patch as generated by diff which conforms to the patch submission and
@@ -39,15 +39,15 @@ patch
 Priority:
 ---------
 critical
-    Bugs and patches which deal with data loss and security issues
-    no feature request can be critical.
+    Bugs and patches which deal with data loss and security issues.
+    No feature request can be critical.
 
 important
-    Bugs which makes ffmpeg unusable for a significant number of users, and
+    Bugs which make ffmpeg unusable for a significant number of users, and
     patches fixing them.
-    examples here might be completely broken mpeg4 decoding or a build issue
-    on linux
-    while broken 4xm decoding or broken os2 build would not be important, the
+    Examples here might be completely broken mpeg4 decoding or a build issue
+    on Linux.
+    While broken 4xm decoding or broken OS/2 build would not be important, the
     separation to normal is somewhat fuzzy ...
     For feature requests this priority would be used for things many people
     want.
@@ -57,8 +57,8 @@ normal
 
 minor
     Bugs and patches about things like spelling errors, "mp2" instead of
-    "mp3" being shown and such
-    Feature requests about things few people want or which don't make a big
+    "mp3" being shown and such.
+    Feature requests about things few people want or which do not make a big
     difference.
 
 wish
@@ -87,8 +87,8 @@ Type/Status/Substatus:
     users
 
 */open/open
-    Issues which have been briefly looked at and which didnt look outright
-    invalid
+    Issues which have been briefly looked at and which did not look outright
+    invalid.
     This implicates that no real more detailed state applies yet. And the
     more detailed states below implicate that the issue has been briefly
     looked at.
@@ -105,8 +105,8 @@ bug/open/reproduced
 
 bug/open/analyzed
     Bugs which have been analyzed and where it is understood what causes them
-    and which exact chain of events triggers them. This analyzis should be
-    available as a message in the bugreport
+    and which exact chain of events triggers them. This analysis should be
+    available as a message in the bugreport.
     Note, do not change the status to analyzed without also providing a clear
     and understandable analysis.
     This state implicates that the bug either has been reproduced or that
@@ -115,38 +115,38 @@ bug/open/analyzed
 bug/open/needs_more_info
     Bugreports which are incomplete and or where more information is needed
     from the submitter or another person who can provide the info.
-    This state implicates that the bug has not been analyzed or reproduced
+    This state implicates that the bug has not been analyzed or reproduced.
 
 bug/closed/fixed
     Bugs which have to the best of our knowledge been fixed.
 
 bug/closed/wont_fix
     Bugs which we will not fix, the reasons here could be legal, philosophical
-    or others
+    or others.
 
 bug/closed/works_for_me
     Bugs for which sufficient information was provided to reproduce but
-    reproduction failed that is the code seems to work correctly to the
+    reproduction failed - that is the code seems to work correctly to the
     best of our knowledge.
 
 patch/open/approved
     Patches which have been reviewed and approved by a developer.
     Such patches can be applied anytime by any other developer after some
     reasonable testing (compile + regression tests + does the patch do
-    what the author claimed)
+    what the author claimed).
 
 patch/open/needs_changes
-    Patches which have been reviewed and need changes to be accepted
+    Patches which have been reviewed and need changes to be accepted.
 
 patch/closed/applied
-    Patches which have been applied
+    Patches which have been applied.
 
 patch/closed/rejected
-    Patches which have been rejected
+    Patches which have been rejected.
 
 feature_request/open/needs_more_info
     Feature requests where its not clear what exactly is wanted
-    (these also could be closed as invalid ...)
+    (these also could be closed as invalid ...).
 
 feature_request/closed/implemented
     Feature requests which have been implemented.