Remove remaining tickets

Author: kwankyu

src/doc/en/developer/git_advanced.rst

@@ -63,7 +63,7 @@ that is not associated to any local branch::
 This is perfectly fine. You can switch to an existing branch (with the
 usual ``git checkout my_branch``) and back to your detached head.
 
-Detached heads can be used to your advantage when reviewing tickets. Just check
+Detached heads can be used to your advantage when reviewing PRs. Just check
 out the commit (look at the "Commits" tab of the PR) that you are reviewing as
 a detached head. Then you can look at the changes and run tests in the detached
 head. When you are finished with the review, you just abandon the detached

src/doc/en/developer/packaging_sage_library.rst

@@ -167,7 +167,7 @@ The source directory of a distribution package, such as
   the current development release is ``9.7.beta8``, then such a
   version could be marked ``9.7.beta8.post1``.
 
-  Also sometimes when working on tickets it may be necessary to
+  Also sometimes when working on PRs it may be necessary to
   increment the version because a new feature is needed in another
   distribution package. Such versions should be marked by using the
   version number of the anticipated next development release and

src/doc/en/developer/review.rst

@@ -157,7 +157,7 @@ lisp, gmp), it is no longer a problem that belongs in our tracker.
 If your distribution's Pari package is buggy for example, file a
 bug report with them. We are usually willing and able to solve
 the problem, but there are no guarantees that we will help you
-out. Looking at the open number of tickets that are Sage specific,
+out. Looking at the open number of PRs that are Sage specific,
 you hopefully will understand why.
 
 **No Support Discussions**: GitHub is not meant to
@@ -184,7 +184,7 @@ Sage Release Manager uses to make releases. Here it is as of 2023:
 **Beta Release Stage**: For preparing a new beta release or the first release
 candidate, all positively reviewed PRs with the forthcoming release
 milestone are considered. PRs that have dependencies not merged yet are ignored.
-The Release Manager merges PRs in batches of 10 to 20 tickets, taking the
+The Release Manager merges PRs in batches of 10 to 20 PRs, taking the
 PR priority into account. If a merge conflict of a PR to the Release
 Manager's branch occurs, the PR is set back to "needs work" status by the
 Release Manager, and the list of the PRs already merged to the Release

src/doc/en/developer/tools.rst

@@ -162,15 +162,15 @@ more thorough check::
 When preparing a branch for a PR that adds new code,
 developers should verify that ``./sage -tox -e pycodestyle`` does not
 issue warnings for the added code.  This will avoid later cleanup
-tickets as the Sage codebase is moving toward full PEP 8 compliance.
+PRs as the Sage codebase is moving toward full PEP 8 compliance.
 
 On the other hand, it is usually not advisable to mix coding-style
 fixes with productive changes on the same PR because this would
 makes it harder for reviewers to evaluate the changes.
 
 By passing the options ``--count -qq`` we can reduce the output to
 only show the number of style violation warnings.  This can be helpful
-for planning work on coding-style clean-up tickets that focus on one
+for planning work on coding-style clean-up PRs that focus on one
 or a few related issues::
 
   $ ./sage -tox -e pycodestyle -- --count -qq src/sage

src/doc/en/developer/walkthrough.rst

@@ -251,10 +251,10 @@ time.
 .. NOTE::
 
     If you have `pulled a branch from the GitHub Sage repository
-    <https://doc.sagemath.org/html/en/developer/manual_git.html#checking-out-tickets>`_,
-    it may depend on changes to third-party packages, so ``./sage -br``
-    may fail.  If this happens (and you believe the code in this branch
-    should compile), try running ``make build``.
+    <https://doc.sagemath.org/html/en/developer/workflows.html#checking-out-an-existing-pr>`_,
+    it may depend on changes to third-party packages, so ``./sage -br`` may
+    fail.  If this happens (and you believe the code in this branch should
+    compile), try running ``make build``.
 
 Rarely there are conflicts with other packages,
 or with the already-installed older version of the package that you

src/doc/en/faq/faq-contribute.rst

@@ -172,9 +172,9 @@ I submitted a bug fix to the GitHub Sage repo several weeks ago. Why are you ign
 """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 
 We are not trying to ignore your branch. Most people who work on Sage do so
-in their free time. With hundreds of open tickets of varying degrees of
-impacts on the whole Sage community, people who work on tickets need
-to prioritize their time and work on those tickets that interest
+in their free time. With hundreds of open PRs of varying degrees of
+impacts on the whole Sage community, people who work on PRs need
+to prioritize their time and work on those PRs that interest
 them. Sometimes you may be the only person who understands your
 branch. In that case, you are encouraged to take extra care to make it
 as easy as possible for anyone to review. Here are some
@@ -189,7 +189,7 @@ tips on making your branch easy to review:
 * Have you clearly described how your branch solves the problem under
   consideration?
 * Have you clearly described how to test the changes in your branch?
-* Have you listed any tickets that your branch depends on?
+* Have you listed any issues/PRs that your branch depends on?
 * Is your branch based on a recent (preferably, the latest) Sage beta version?
 * Does your branch
   `follow relevant conventions <https://doc.sagemath.org/html/en/developer/#writing-code-for-sage>`_

src/doc/en/faq/faq-general.rst

@@ -258,7 +258,7 @@ testing <../developer/portability_testing.html>`_ in the Developer's
 Guide for details.
 
 
-With so many bugs in Sage and hundreds of open tickets, why don't you produce a stabilization release?
+With so many bugs in Sage and hundreds of open issues, why don't you produce a stabilization release?
 """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 
 Any software package contains bug. With something as complex as Sage, neither
@@ -269,7 +269,7 @@ A Sage release cycle lasts for a few months, with several betas appearing at
 1-2 week intervals, followed by several release candidates (as of 2022). Under
 this schedule and with the limited capacity of the Sage developer community,
 the project cannot make stabilization releases. However, important
-bug fix tickets are merged with high priority and will be available in the
+bug fix PRs are merged with high priority and will be available in the
 development release. Thanks to rigorous integration testing by our dedicated
 Release Manager, development releases (betas and release candidates) are
 generally safe and reliable to use.