Update CONTRIBUTING.md to fix failing workflow

CONTRIBUTING.md

@@ -4,7 +4,7 @@ After following the instructions to set up your instance, please read below for
 
 ## Guidelines for Backend Development
 
-### Background
+### Backend Background
 
 Gitea uses Golang as the backend programming language. It uses many third-party packages and also writes some itself. For example, Gitea uses [Chi](https://github.com/go-chi/chi) as a basic web framework. [Xorm](https://xorm.io/) is an ORM framework that is used to interact with the database. So it's very important to manage these packages. Please take the below guidelines before you start to write backend code.
 
@@ -53,7 +53,7 @@ Since some packages use the same package name, you might encounter packages like
 
 ## Guidelines for Frontend Development
 
-### Background
+### Frontend Background
 
 Gitea uses `Fomantic-UI` (based on jQuery) and `Vue3` for its frontend.
 
@@ -150,7 +150,7 @@ Gitea is using `Vue3` now. We decided not to introduce `JSX` to keep the HTML an
 
 ### UI Examples
 
-Gitea uses some custom UI elements and customizes others to better integrate them into the general UI approach. When running Gitea in development mode (`RUN_MODE=dev`), a page with standardized UI examples is available at `http(s)://your-gitea-url:port/devtest`. 
+Gitea uses some custom UI elements and customizes others to better integrate them into the general UI approach. When running Gitea in development mode (`RUN_MODE=dev`), a page with standardized UI examples is available at `http(s)://your-gitea-url:port/devtest`.
 
 ## Styleguide
 
@@ -180,9 +180,9 @@ Here's how to run the test suite:
 
 # PRs
 
-Always open PRs with any changes and do not merge directly into main. 
+Always open PRs with any changes and do not merge directly into main.
 
-## General Guidelines
+## General Guidelines for GitHub
 
 1. Write clear and meaningful commit messages.
 
@@ -204,29 +204,29 @@ Guidelines for Pull Requests
 
 Pull requests (PRs) are a mechanism where proposed changes to a codebase are submitted for review and integration, facilitating collaborative development. When you are ready to integrate your changes into main, please submit a PR. Rationale: Code review allows other collaborators to provide feedback and catch potential issues.
 
-You can notify other collaborators on the right side of your screen when making a PR and you can send them the link directly for review. 
+You can notify other collaborators on the right side of your screen when making a PR and you can send them the link directly for review.
 
 Before submitting a pull request, ensure that most or all of the following criteria are met:
 
 - [ ] Title is descriptive
-
-- [ ] Detailed description of the changes made in the PR 
 
-- [ ] If there is a specific issue then it is referenced in the description (eg. "Closes," "Fixes," or "Resolves" issue X) 
+- [ ] Detailed description of the changes made in the PR
 
-- [ ] Feature branch is up-to-date with target branch by regular rebasing 
+- [ ] If there is a specific issue then it is referenced in the description (eg. "Closes," "Fixes," or "Resolves" issue X)
 
-- [ ] Extensive testing was run before opening PR 
+- [ ] Feature branch is up-to-date with target branch by regular rebasing
 
-- [ ] No merge conflicts 
+- [ ] Extensive testing was run before opening PR
 
-## Guidelines for Pull Request Comments 
+- [ ] No merge conflicts
 
-In the pull request comments, provide a detailed description of additions, removals, and fixes, including explanations for changes in the implementation; leverage markdown for well-structured comments with bullet points and consider adding images or GIFs, particularly for UI modifications (drag and drop images are supported). If any aspects of the issue were not addressed, leave a note at the bottom of the comments for ongoing reference. 
+## Guidelines for Pull Request Comments
 
-In essence, the goal is (assuming PR has no conflicts with main) that someone who has been collaborating with you should easily be able to approve/add comments to the PR without having to go to the code or do any test runs. All of this information should be communicated with them in the PR notes. 
+In the pull request comments, provide a detailed description of additions, removals, and fixes, including explanations for changes in the implementation; leverage markdown for well-structured comments with bullet points and consider adding images or GIFs, particularly for UI modifications (drag and drop images are supported). If any aspects of the issue were not addressed, leave a note at the bottom of the comments for ongoing reference.
 
-## Exemplar Pull Request 
+In essence, the goal is (assuming PR has no conflicts with main) that someone who has been collaborating with you should easily be able to approve/add comments to the PR without having to go to the code or do any test runs. All of this information should be communicated with them in the PR notes.
+
+## Exemplar Pull Request
 
 <img width="800" alt="image" src="https://github.com/user-attachments/assets/0882bdaf-ecd0-4024-b7c9-dc60edd3c91c">