minor edits, remove fancy single quotes

Author: LiNk-NY

package-submission.Rmd

@@ -38,7 +38,7 @@ _Bioconductor_ packages are broadly defined by four main package types:
 
 * Software Packages. Most packages contributed by users are software
   packages. Software packages provide implementation of algorithms
-  (e.g. statistical analysis), access to resources (e.g. biomart, or NCBI) or
+  (e.g. statistical analysis), access to resources (e.g. `biomaRt`, or NCBI) or
   visualizations (e.g. volcano plots, pathways plots). Instructions for creating
   Software packages can be found here: [Package guidelines][guidelines].
 
@@ -85,7 +85,7 @@ package contributor discontinues package maintenance. See Bioconductor's package
 [end-of-life policy][] for more details.
 
 ii) Uniqueness of package name. Packages should be named in a way that does not
-conflict (irrespective of case) with any current or past BIOCONDUCTOR package,
+conflict (irrespective of case) with any current or past Bioconductor package,
 nor any current or past CRAN package.
 
 See [Package naming guidelines](#package-name) for more guidelines.
@@ -97,24 +97,24 @@ package maintenance responsibilities. Package authors are expected to:
 
 * Follow Bioconductor guidelines
 
-  These include standard [guidelines][guidelines], [version numbering][versioning],
-  [coding style](#r-code), [code performance
-  requirements](#correctness-space-and-time), [memory usage](#memory), [using
-  existing data classes][bioc-common], and the other requirements described
-  below.
+  These include standard [guidelines][guidelines],
+  [version numbering][versioning], [coding style](#r-code),
+  [code performance requirements](#correctness-space-and-time),
+  [memory usage](#memory), [using existing data classes][bioc-common],
+  and the other requirements described below.
 
 * Follow the release cycle of Bioconductor
 
   There are two releases each year, around April and October. The
   [release schedule][release-schedule] will indicate the timetables and
   deadlines for each release. A release cycle typically produces two
-  versions of packages, ‘devel’ and ‘release’. It is important to be familiar
+  versions of packages, 'devel' and 'release'. It is important to be familiar
   with these branch concepts. Once your package has been accepted, it will
-  initially be in the ‘devel’ branch.  The current devel branch becomes the
+  initially be in the 'devel' branch.  The current devel branch becomes the
   next release. Most users are expected to use the release branch, so they will
   not immediately have access to your package until the next release.
   Bug fixes can be fixed in both branches, while new features should only
-  be added to the ‘devel’ branch.
+  be added to the 'devel' branch.
 
 * Maintain the package using version control
 
@@ -175,7 +175,7 @@ package maintenance responsibilities. Package authors are expected to:
   the issue you are opening.  You cannot specify any alternative branches; the
   default branch is utilized. The default branch must contain only package
   code. Any files or directories for other applications (Github Actions,
-  devtool, etc) should be in a different branch. If you are submitting two
+  devtools, etc) should be in a different branch. If you are submitting two
   highly related packages or circular dependent packages please see
   [here][cirdep]. The lighter dependent or package that can be installed without
   a dependency should be submitted first; this is generally the associated data
@@ -370,5 +370,3 @@ package documentation and structure.  Use the
 <[email protected]> to obtain additional support.
 
 * Support Email: <[email protected]>
-
-