diff --git a/dev-support/Dockerfile b/dev-support/flaky-tests/Dockerfile
similarity index 88%
rename from dev-support/Dockerfile
rename to dev-support/flaky-tests/Dockerfile
index 39fd5645e88..5b8dcc60bdf 100644
--- a/dev-support/Dockerfile
+++ b/dev-support/flaky-tests/Dockerfile
@@ -22,7 +22,7 @@
 # dev-support/flaky-tests/flaky-reporting.Jenkinsfile
 FROM ubuntu:22.04
 
-COPY . /hbase/dev-support
+COPY dev-support/flaky-tests/python-requirements.txt /hbase/dev-support/flaky-tests/
 
 RUN DEBIAN_FRONTEND=noninteractive apt-get -qq -y update \
     && DEBIAN_FRONTEND=noninteractive apt-get -qq -y install --no-install-recommends \
@@ -30,4 +30,4 @@ RUN DEBIAN_FRONTEND=noninteractive apt-get -qq -y update \
       python3-pip='22.0.2+dfsg-*' \
     && apt-get clean \
     && rm -rf /var/lib/apt/lists/* \
-    && pip3 install --no-cache-dir -r /hbase/dev-support/python-requirements.txt
+    && pip3 install --no-cache-dir -r /hbase/dev-support/flaky-tests/python-requirements.txt
diff --git a/dev-support/flaky-tests/flaky-reporting.Jenkinsfile b/dev-support/flaky-tests/flaky-reporting.Jenkinsfile
index f5090095453..5f1f92f03c6 100644
--- a/dev-support/flaky-tests/flaky-reporting.Jenkinsfile
+++ b/dev-support/flaky-tests/flaky-reporting.Jenkinsfile
@@ -45,7 +45,7 @@ pipeline {
           declare -a flaky_args
           flaky_args=("${flaky_args[@]}" --urls "${JENKINS_URL}/job/HBase%20Nightly/job/${BRANCH_NAME}" --is-yetus True --max-builds 20)
           flaky_args=("${flaky_args[@]}" --urls "${JENKINS_URL}/job/HBase-Flaky-Tests/job/${BRANCH_NAME}" --is-yetus False --max-builds 50)
-          docker build -t hbase-dev-support dev-support
+          docker build -t hbase-dev-support -f dev-support/flaky-tests/Dockerfile .
           docker run --ulimit nproc=12500 -v "${WORKSPACE}":/hbase -u `id -u`:`id -g` --workdir=/hbase hbase-dev-support \
             ./dev-support/flaky-tests/report-flakies.py --mvn -v -o output "${flaky_args[@]}"
         '''
diff --git a/dev-support/python-requirements.txt b/dev-support/flaky-tests/python-requirements.txt
similarity index 100%
rename from dev-support/python-requirements.txt
rename to dev-support/flaky-tests/python-requirements.txt
diff --git a/src/main/asciidoc/_chapters/developer.adoc b/src/main/asciidoc/_chapters/developer.adoc
index 30a793d5430..20f96921b1d 100644
--- a/src/main/asciidoc/_chapters/developer.adoc
+++ b/src/main/asciidoc/_chapters/developer.adoc
@@ -2254,75 +2254,31 @@ If you are new to submitting patches to open source or new to submitting patches
  link:https://commons.apache.org/[Apache Commons Project].
 It provides a nice overview that applies equally to the Apache HBase Project.
 
-[[submitting.patches.create]]
-==== Create Patch
-
-Make sure you review <<common.patch.feedback,common.patch.feedback>> for code style. If your
-patch
+Make sure you review <<common.patch.feedback,common.patch.feedback>> for code style. If your patch
 was generated incorrectly or your code does not adhere to the code formatting guidelines, you may
 be asked to redo some work.
 
-
-.Using submit-patch.py (recommended)
+HBase enforces code style via a maven plugin. After you've written up your changes, apply the
+formatter before committing.
 
 [source,bourne]
-----
-$ dev-support/submit-patch.py -jid HBASE-xxxxx
-----
-
-Use this script to create patches, upload to jira and optionally create/update reviews on
-Review Board. Patch name is automatically formatted as _(JIRA).(branch name).(patch number).patch_
- to follow Yetus' naming rules. Use `-h` flag to know detailed usage information. Most useful options
-are:
-
-* `-b BRANCH, --branch BRANCH` : Specify base branch for generating the diff. If not specified,
-tracking branch is used. If there is no tracking branch, error will be thrown.
-* `-jid JIRA_ID, --jira-id JIRA_ID` : If used, deduces next patch version from attachments in the
-jira and uploads the new patch. Script will ask for jira username/password for authentication.
-If not set, patch is named <branch>.patch.
-
-By default, it'll also create/update review board. To skip that action, use `-srb` option. It uses
-'Issue Links' in the jira to figure out if a review request already exists. If no review
-request is present, then creates a new one and populates all required fields using jira summary,
-patch description, etc. Also adds this review's link to the jira.
-
-Save authentication credentials (optional)::
-Since attaching patches on JIRA and creating/changing review request on ReviewBoard requires
-valid user authentication, the script will prompt you for username and password. To avoid the hassle every
-time, set up `~/.apache-creds` with login details and encrypt it by following the steps in footer
-of script's help message.
-
-Python dependencies:: To install required python dependencies, execute
-`pip install -r dev-support/python-requirements.txt` from the master branch.
-
-.Manually
-
-  . Use `git rebase -i` first, to combine (squash) smaller commits into a single larger one.
-  . Create patch using IDE or Git commands. `git format-patch` is preferred since it preserves patch
-    author's name and commit message. Also, it handles binary files by default, whereas `git diff`
-    ignores them unless you use the `--binary` option.
-  . Patch name should be as follows to adhere to Yetus' naming convention: +
-    `(JIRA).(branch name).(patch number).patch` +
-    For eg. HBASE-11625.master.001.patch, HBASE-XXXXX.branch-1.2.0005.patch, etc.
-  . Attach the patch to the JIRA using `More->Attach Files` then click on btn:[Submit Patch]
-    button, which'll trigger Hudson job to check patch for validity.
-  . If your patch is longer than a single screen, also create a review on Review Board  and
-    add the link to JIRA. See <<reviewboard,reviewboard>>.
-
+---
+$ mvn spotless:apply
+---
 
+When your commit is ready, present it to the community as a
+link:https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests[GitHub Pull Request].
 
 .Few general guidelines
 * Always patch against the master branch first, even if you want to patch in another branch.
-  HBase committers always apply patches first to the master branch, and backport if necessary.
-* Submit one single patch for a fix. If necessary, squash local commits to merge local commits into
-  a single one first. See this
+  HBase committers always apply patches first to the master branch, and backport as necessary. For
+  complex patches, you may be asked to perform the backport(s) yourself.
+* Submit one single PR for a single fix. If necessary, squash local commits to merge local commits
+  into a single one first. See this
   link:http://stackoverflow.com/questions/5308816/how-to-use-git-merge-squash[Stack Overflow
   question] for more information about squashing commits.
 * Please understand that not every patch may get committed, and that feedback will likely be
   provided on the patch.
-* If you need to revise your patch, leave the previous patch file(s) attached to the JIRA, and
-  upload a new one with incremented patch number. +
-  Click on btn:[Cancel Patch] and then on btn:[Submit Patch] to trigger the presubmit run.
 
 [[submitting.patches.tests]]
 ==== Unit Tests