diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md
deleted file mode 100644
index b752abb794de..000000000000
--- a/.github/pull_request_template.md
+++ /dev/null
@@ -1,9 +0,0 @@
-<!-- start tips --> 
-Please check the following:
-1. Make sure you are targeting the `main` branch, pull requests on release branches are only allowed for backports.
-2. Make sure you have read contributing guidelines: https://github.com/go-gitea/gitea/blob/main/CONTRIBUTING.md .
-3. Describe what your pull request does and which issue you're targeting (if any).
-4. It is recommended to enable "Allow edits by maintainers", so maintainers can help more easily.
-5. Your input here will be included in the commit message when this PR has been merged. If you don't want some content to be included, please separate them with a line like `---`.
-6. Delete all these tips before posting.
-<!-- end tips -->
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 5d20bc258947..e8b3a293b982 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,605 +1,246 @@
 # Contribution Guidelines
 
-<details><summary>Table of Contents</summary>
-
-- [Contribution Guidelines](#contribution-guidelines)
-  - [Introduction](#introduction)
-  - [Issues](#issues)
-    - [How to report issues](#how-to-report-issues)
-    - [Types of issues](#types-of-issues)
-    - [Discuss your design before the implementation](#discuss-your-design-before-the-implementation)
-    - [Issue locking](#issue-locking)
-  - [Building Gitea](#building-gitea)
-  - [Dependencies](#dependencies)
-    - [Backend](#backend)
-    - [Frontend](#frontend)
-  - [Design guideline](#design-guideline)
-  - [Styleguide](#styleguide)
-  - [Copyright](#copyright)
-  - [Testing](#testing)
-  - [Translation](#translation)
-  - [Code review](#code-review)
-    - [Pull request format](#pull-request-format)
-    - [PR title and summary](#pr-title-and-summary)
-    - [Milestone](#milestone)
-    - [Labels](#labels)
-    - [Breaking PRs](#breaking-prs)
-      - [What is a breaking PR?](#what-is-a-breaking-pr)
-      - [How to handle breaking PRs?](#how-to-handle-breaking-prs)
-    - [Maintaining open PRs](#maintaining-open-prs)
-    - [Getting PRs merged](#getting-prs-merged)
-    - [Final call](#final-call)
-    - [Commit messages](#commit-messages)
-      - [PR Co-authors](#pr-co-authors)
-      - [PRs targeting `main`](#prs-targeting-main)
-      - [Backport PRs](#backport-prs)
-  - [Documentation](#documentation)
-  - [API v1](#api-v1)
-    - [GitHub API compatibility](#github-api-compatibility)
-    - [Adding/Maintaining API routes](#addingmaintaining-api-routes)
-    - [When to use what HTTP method](#when-to-use-what-http-method)
-    - [Requirements for API routes](#requirements-for-api-routes)
-  - [Backports and Frontports](#backports-and-frontports)
-    - [What is backported?](#what-is-backported)
-    - [How to backport?](#how-to-backport)
-    - [Format of backport PRs](#format-of-backport-prs)
-    - [Frontports](#frontports)
-  - [Developer Certificate of Origin (DCO)](#developer-certificate-of-origin-dco)
-  - [Release Cycle](#release-cycle)
-  - [Maintainers](#maintainers)
-  - [Technical Oversight Committee (TOC)](#technical-oversight-committee-toc)
-    - [TOC election process](#toc-election-process)
-    - [Current TOC members](#current-toc-members)
-    - [Previous TOC/owners members](#previous-tocowners-members)
-  - [Governance Compensation](#governance-compensation)
-  - [TOC \& Working groups](#toc--working-groups)
-  - [Roadmap](#roadmap)
-  - [Versions](#versions)
-  - [Releasing Gitea](#releasing-gitea)
-
-</details>
-
-## Introduction
-
-This document explains how to contribute changes to the Gitea project. \
-It assumes you have followed the [installation instructions](https://docs.gitea.com/category/installation). \
-Sensitive security-related issues should be reported to [security@gitea.io](mailto:security@gitea.io).
-
-For configuring IDEs for Gitea development, see the [contributed IDE configurations](contrib/ide/).
-
-## Issues
-
-### How to report issues
-
-Please search the issues on the issue tracker with a variety of related keywords to ensure that your issue has not already been reported.
-
-If your issue has not been reported yet, [open an issue](https://github.com/go-gitea/gitea/issues/new)
-and answer the questions so we can understand and reproduce the problematic behavior. \
-Please write clear and concise instructions so that we can reproduce the behavior — even if it seems obvious. \
-The more detailed and specific you are, the faster we can fix the issue. \
-It is really helpful if you can reproduce your problem on a site running on the latest commits, i.e. <https://try.gitea.io>, as perhaps your problem has already been fixed on a current version. \
-Please follow the guidelines described in [How to Report Bugs Effectively](http://www.chiark.greenend.org.uk/~sgtatham/bugs.html) for your report.
-
-Please be kind, remember that Gitea comes at no cost to you, and you're getting free help.
-
-### Types of issues
-
-Typically, issues fall in one of the following categories:
-
-- `bug`: Something in the frontend or backend behaves unexpectedly
-- `security issue`: bug that has serious implications such as leaking another users data. Please do not file such issues on the public tracker and send a mail to security@gitea.io instead
-- `feature`: Completely new functionality. You should describe this feature in enough detail that anyone who reads the issue can understand how it is supposed to be implemented
-- `enhancement`: An existing feature should get an upgrade
-- `refactoring`: Parts of the code base don't conform with other parts and should be changed to improve Gitea's maintainability
-
-### Discuss your design before the implementation
-
-We welcome submissions. \
-If you want to change or add something, please let everyone know what you're working on — [file an issue](https://github.com/go-gitea/gitea/issues/new) or comment on an existing one before starting your work!
-
-Significant changes such as new features must go through the change proposal process before they can be accepted. \
-This is mainly to save yourself the trouble of implementing it, only to find out that your proposed implementation has some potential problems. \
-Furthermore, this process gives everyone a chance to validate the design, helps prevent duplication of effort, and ensures that the idea fits inside
-the goals for the project and tools.
-
-Pull requests should not be the place for architecture discussions.
-
-### Issue locking
-
-Commenting on closed or merged issues/PRs is strongly discouraged.
-Such comments will likely be overlooked as some maintainers may not view notifications on closed issues, thinking that the item is resolved.
-As such, commenting on closed/merged issues/PRs may be disabled prior to the scheduled auto-locking if a discussion starts or if unrelated comments are posted.
-If further discussion is needed, we encourage you to open a new issue instead and we recommend linking to the issue/PR in question for context.
-
-## Building Gitea
+After following the instructions to set up your instance, please read below for guidelines on contributions to RIA Hub.
 
-See the [development setup instructions](https://docs.gitea.com/development/hacking-on-gitea).
+## Guidelines for Backend Development
 
-## Dependencies
+### Backend Background
 
-### Backend
+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.
 
-Go dependencies are managed using [Go Modules](https://go.dev/cmd/go/#hdr-Module_maintenance). \
-You can find more details in the [go mod documentation](https://go.dev/ref/mod) and the [Go Modules Wiki](https://github.com/golang/go/wiki/Modules).
+### Package Design Guideline
 
-Pull requests should only modify `go.mod` and `go.sum` where it is related to your change, be it a bugfix or a new feature. \
-Apart from that, these files should only be modified by Pull Requests whose only purpose is to update dependencies.
+#### Packages List
 
-The `go.mod`, `go.sum` update needs to be justified as part of the PR description,
-and must be verified by the reviewers and/or merger to always reference
-an existing upstream commit.
+To maintain understandable code and avoid circular dependencies, it is important to have a good code structure. The Gitea backend is divided into the following parts:
 
-### Frontend
+- `build`: Scripts to help build Gitea.
+- `cmd`: All Gitea actual subcommands, including web, doctor, serv, hooks, admin, etc. `web` will start the web service. `serv` and `hooks` will be invoked by Git or OpenSSH. Other subcommands could help to maintain Gitea.
+- `tests`: Common test utility functions.
+  - `tests/integration`: Integration tests, to test back-end regressions.
+  - `tests/e2e`: End-to-end tests, to test front-end and back-end compatibility and visual regressions.
+- `models`: Contains the data structures used by xorm to construct database tables. It also contains functions to query and update the database. Dependencies to other Gitea code should be avoided, with exceptions like logging.
+  - `models/db`: Basic database operations. All other `models/xxx` packages should depend on this package. The `GetEngine` function should only be invoked from `models/`.
+  - `models/fixtures`: Sample data used in unit tests and integration tests. One yml file means one table, which will be loaded into the database when tests begin.
+  - `models/migrations`: Stores database migrations between versions. PRs that change a database structure MUST also have a migration step.
+- `modules`: Different modules to handle specific functionality in Gitea. (Work in Progress: Some should be moved to services, particularly those that depend on models.)
+  - `modules/setting`: Stores all system configurations read from ini files and is referenced everywhere. Should be used as function parameters when possible.
+  - `modules/git`: Package to interact with Git command line or Gogit package.
+- `public`: Compiled frontend files (JavaScript, images, CSS, etc.).
+- `routers`: Handles server requests. As it uses other Gitea packages to serve requests, other packages (models, modules, or services) must not depend on routers.
+  - `routers/api`: Contains routers for `/api/v1`, aimed to handle RESTful API requests.
+  - `routers/install`: Responds only when the system is in INSTALL mode (`INSTALL_LOCK=false`).
+  - `routers/private`: Invoked only by internal subcommands, especially serv and hooks.
+  - `routers/web`: Handles HTTP requests from web browsers or Git SMART HTTP protocols.
+- `services`: Support functions for common routing operations or command executions. Uses models and modules to handle requests.
+- `templates`: Golang templates for generating HTML output.
 
-For the frontend, we use [npm](https://www.npmjs.com/).
+### Package Dependencies
 
-The same restrictions apply for frontend dependencies as for backend dependencies, with the exceptions that the files for it are `package.json` and `package-lock.json`, and that new versions must always reference an existing version.
+Since Golang doesn't support import cycles, we have to decide package dependencies carefully. There are some levels between packages. Below is the ideal package dependency direction:
 
-## Design guideline
+`cmd -> routers -> services -> models -> modules`
 
-Depending on your change, please read the
+From left to right, packages on the left can depend on packages on the right, but packages on the right MUST not depend on those on the left. Subpackages on the same level may depend according to this level's rules.
 
-- [backend development guideline](https://docs.gitea.com/contributing/guidelines-backend)
-- [frontend development guideline](https://docs.gitea.com/contributing/guidelines-frontend)
-- [refactoring guideline](https://docs.gitea.com/contributing/guidelines-refactoring)
+### Package Name
 
-## Styleguide
-
-You should always run `make fmt` before committing to conform to Gitea's styleguide.
-
-## Copyright
-
-New code files that you contribute should use the standard copyright header:
-
-```
-// Copyright <current year> The Gitea Authors. All rights reserved.
-// SPDX-License-Identifier: MIT
-```
-
-Afterwards, copyright should only be modified when the copyright author changes.
-
-## Testing
-
-Before submitting a pull request, run all tests to make sure your changes don't cause a regression elsewhere.
-
-Here's how to run the test suite:
-
-- code lint
-
-|                       |                                                                   |
-| :-------------------- | :---------------------------------------------------------------- |
-|``make lint``          | lint everything (not needed if you only change the front- **or** backend)    |
-|``make lint-frontend`` | lint frontend files  |
-|``make lint-backend``  | lint backend files   |
+For top-level packages, use a plural as the package name, i.e., `services`, `models`. For subpackages, use the singular, i.e., `services/user`, `models/repository`.
 
-- run tests (we suggest running them on Linux)
+### Import Alias
 
-|  Command                               | Action                                           |              |
-| :------------------------------------- | :----------------------------------------------- | ------------ |
-|``make test[\#SpecificTestName]``       |  run unit test(s)  | |
-|``make test-sqlite[\#SpecificTestName]``|  run [integration](tests/integration) test(s) for SQLite |[More details](tests/integration/README.md)  |
-|``make test-e2e-sqlite[\#SpecificTestName]``|  run [end-to-end](tests/e2e) test(s) for SQLite |[More details](tests/e2e/README.md)  |
+Since some packages use the same package name, you might encounter packages like `modules/user`, `models/user`, and `services/user`. When these packages are imported in one Go file, it's difficult to know which package is being used and whether it's a variable or import name. Therefore, it is recommended to use import aliases. To differentiate from package variables (which are commonly in camelCase), use snake_case for import aliases, e.g., `import user_service "code.gitea.io/gitea/services/user"`.
 
-## Translation
+## Guidelines for Frontend Development
 
-All translation work happens on [Crowdin](https://crowdin.com/project/gitea).
-The only translation that is maintained in this repository is [the English translation](https://github.com/go-gitea/gitea/blob/main/options/locale/locale_en-US.ini).
-It is synced regularly with Crowdin. \
-Other locales on main branch **should not** be updated manually as they will be overwritten with each sync. \
-Once a language has reached a **satisfactory percentage** of translated keys (~25%), it will be synced back into this repo and included in the next released version.
+### Frontend Background
 
-The tool `go run build/backport-locale.go` can be used to backport locales from the main branch to release branches that were missed.
+Gitea uses `Fomantic-UI` (based on jQuery) and `Vue3` for its frontend.
 
-## Code review
+The HTML pages are rendered by Go HTML Template.
 
-### Pull request format
+The source files can be found in the following directories:
 
-Please try to make your pull request easy to review for us. \
-For that, please read the [*Best Practices for Faster Reviews*](https://github.com/kubernetes/community/blob/261cb0fd089b64002c91e8eddceebf032462ccd6/contributors/guide/pull-requests.md#best-practices-for-faster-reviews) guide. \
-It has lots of useful tips for any project you may want to contribute to. \
-Some of the key points:
+- CSS styles: `web_src/css/`
+- JavaScript files: `web_src/js/`
+- Vue components: `web_src/js/components/`
+- Go HTML templates: `templates/`
 
-- Make small pull requests. \
-  The smaller, the faster to review and the more likely it will be merged soon.
-- Don't make changes unrelated to your PR. \
-  Maybe there are typos on some comments, maybe refactoring would be welcome on a function... \
-  but if that is not related to your PR, please make *another* PR for that.
-- Split big pull requests into multiple small ones. \
-  An incremental change will be faster to review than a huge PR.
-- Allow edits by maintainers. This way, the maintainers will take care of merging the PR later on instead of you.
+### General Guidelines
 
-### PR title and summary
+We recommend the following style guides:
 
-In the PR title, describe the problem you are fixing, not how you are fixing it. \
-Use the first comment as a summary of your PR. \
-In the PR summary, you can describe exactly how you are fixing this problem.
+- [Google HTML/CSS Style Guide](https://google.github.io/styleguide/htmlcssguide.html)
+- [Google JavaScript Style Guide](https://google.github.io/styleguide/jsguide.html)
 
-Keep this summary up-to-date as the PR evolves. \
-If your PR changes the UI, you must add **after** screenshots in the PR summary. \
-If you are not implementing a new feature, you should also post **before** screenshots for comparison.
+#### Gitea Specific Guidelines
 
-If you are implementing a new feature, your PR will only be merged if your screenshots are up to date.\
-Furthermore, feature PRs will only be merged if their summary contains a clear usage description (understandable for users) and testing description (understandable for reviewers).
-You should strive to combine both into a single description.
+- Every feature (`Fomantic-UI`/`jQuery` module) should be put in separate files/directories.
+- HTML ids and classes should use **kebab-case** and contain 2-3 feature-related keywords.
+- HTML ids and classes used in JavaScript should be unique across the entire project and contain 2-3 feature-related keywords. Use the `js-` prefix for classes that are only used in JavaScript.
+- Avoid overwriting CSS styling for framework-provided classes. Use new class names with 2-3 feature-related keywords. Gitea's helper CSS classes in `helpers.less` could be useful.
+- The backend can pass complex data to the frontend by using `ctx.PageData["myModuleData"] = map[]{}`, but do not expose entire models to the frontend to avoid leaking sensitive data.
+- Simple and SEO-related pages should use Go HTML Template to generate static `Fomantic-UI` HTML output. More complex pages can use `Vue3`.
+- Clarify variable types. Prefer `elem.disabled = true` instead of `elem.setAttribute('disabled', 'anything')`. Prefer `$el.prop('checked', var === 'yes')` instead of `$el.prop('checked', var)`.
+- Use semantic elements. Prefer `<button class="ui button">` over `<div class="ui button">`.
+- Avoid unnecessary `!important` in CSS. Add comments to explain why it's necessary if it cannot be avoided.
+- Avoid mixing different events in one event listener. Use individual event listeners for each event.
+- Custom event names should use the `ce-` prefix.
+- Prefer using `Tailwind CSS`, which is available via the `tw-` prefix (e.g., `tw-relative`). Gitea's helper CSS classes use the `gt-` prefix (e.g., `gt-word-break`), and Gitea's private framework-level CSS classes use the `g-` prefix (e.g., `g-modal-confirm`).
+- Avoid inline scripts and styles as much as possible. It's recommended to put JS code into JS files and use CSS classes. If inline scripts/styles are unavoidable, explain the reason why.
 
-Another requirement for merging PRs is that the PR is labeled correctly.\
-However, this is not your job as a contributor, but the job of the person merging your PR.\
-If you think that your PR was labeled incorrectly, or notice that it was merged without labels, please let us know.
+### Framework Usage
 
-If your PR closes some issues, you must note that in a way that both GitHub and Gitea understand, i.e. by appending a paragraph like
+Mixing different frameworks is discouraged, as it makes code difficult to maintain. A JavaScript module should follow one major framework and adhere to that framework's best practices.
 
-```text
-Fixes/Closes/Resolves #<ISSUE_NR_X>.
-Fixes/Closes/Resolves #<ISSUE_NR_Y>.
-```
+**Recommended implementations:**
 
-to your summary. \
-Each issue that will be closed must stand on a separate line.
+- `Vue + Vanilla JS`
+- `Fomantic-UI` (`jQuery`)
+- `htmx` (for partial page reloads in otherwise static components)
+- `Vanilla JS`
 
-### Milestone
+**Discouraged implementations:**
 
-A PR should only be assigned to a milestone if it will likely be merged into the given version. \
-As a rule of thumb, assume that a PR will stay open for an additional month for every 100 added lines. \
-PRs without a milestone may not be merged.
+- `Vue + Fomantic-UI` (`jQuery`)
+- `jQuery + Vanilla JS`
+- `htmx` with any other framework that requires heavy JS code or unnecessary features like `htmx` scripting (`hx-on`)
 
-### Labels
+For consistent UI, `Vue` components can use `Fomantic-UI` CSS classes. Use `htmx` for simple interactions, as seen in [this PR](https://github.com/go-gitea/gitea/pull/21855). Do not use `htmx` for more advanced reactivity; use another framework like `Vue` or `Vanilla JS`. While mixing frameworks is discouraged, it can work if necessary and if the code is well-designed and maintainable.
 
-Almost all labels used inside Gitea can be classified as one of the following:
+### Fetching Data
 
-- `modifies/…`: Determines which parts of the codebase are affected. These labels will be set through the CI.
-- `topic/…`:  Determines the conceptual component of Gitea that is affected, i.e. issues, projects, or authentication. At best, PRs should only target one component but there might be overlap. Must be set manually.
-- `type/…`: Determines the type of an issue or PR (feature, refactoring, docs, bug, …). If GitHub supported scoped labels, these labels would be exclusive, so you should set **exactly** one, not more or less (every PR should fall into one of the provided categories, and only one).
-- `issue/…` / `pr/…`: Labels that are specific to issues or PRs respectively and that are only necessary in a given context, i.e. `issue/not-a-bug` or `pr/need-2-approvals`
+To fetch data, use wrapper functions `GET`, `POST`, etc. from `modules/fetch.js`. They accept a `data` option for content, will automatically set the CSRF token, and return a `Promise` for a `Response`.
 
-Every PR should be labeled correctly with every label that applies.
+### HTML Attributes and dataset
 
-There are also some labels that will be managed automatically.\
-In particular, these are
+Avoid using `dataset`, as its camel-casing behavior makes attributes hard to grep. However, there are some exceptions:
 
-- the amount of pending required approvals
-- has all `backport`s or needs a manual backport
+**For legacy code:**
 
-### Breaking PRs
+- Refactor `$.data()` to `$.attr()`.
+- Use `$.data()` in rare cases to bind non-string data to elements, but this is discouraged.
 
-#### What is a breaking PR?
+**For new code:**
 
-A PR is breaking if it meets one of the following criteria:
+- Do not use `node.dataset`, use `node.getAttribute` instead.
+- Never bind user data to a DOM node. Use suitable design patterns to describe the relationship between node and data.
 
-- It changes API output in an incompatible way for existing users
-- It removes a setting that an admin could previously set (i.e. via `app.ini`)
-- An admin must do something manually to restore the old behavior
+### Show/Hide Elements
 
-In particular, this means that adding new settings is not breaking.\
-Changing the default value of a setting or replacing the setting with another one is breaking, however.
+For `Vue` components, use `v-if` and `v-show` to show/hide elements. In Go template code, use `.tw-hidden` and `showElem()`, `hideElem()`, or `toggleElem()`. See more details in `.tw-hidden`'s comments.
 
-#### How to handle breaking PRs?
+### Styles and Attributes in Go HTML Template
 
-If your PR has a breaking change, you must add two things to the summary of your PR:
+It is recommended to use:
 
-1. A reasoning why this breaking change is necessary
-2. A `BREAKING` section explaining in simple terms (understandable for a typical user) how this PR affects users and how to mitigate these changes. This section can look for example like
-
-```md
-## :warning: BREAKING :warning:
 ```
-
-Breaking PRs will not be merged as long as not both of these requirements are met.
-
-### Maintaining open PRs
-
-The moment you create a non-draft PR or the moment you convert a draft PR to a non-draft PR is the moment code review starts for it. \
-Once that happens, do not rebase or squash your branch anymore as it makes it difficult to review the new changes. \
-Merge the base branch into your branch only when you really need to, i.e. because of conflicting changes in the mean time. \
-This reduces unnecessary CI runs. \
-Don't worry about merge commits messing up your commit history as every PR will be squash merged. \
-This means that all changes are joined into a single new commit whose message is as described below.
-
-### Getting PRs merged
-
-Changes to Gitea must be reviewed before they are accepted — no matter who
-makes the change, even if they are an owner or a maintainer. \
-The only exception are critical bugs that prevent Gitea from being compiled or started. \
-Specifically, we require two approvals from maintainers for every PR. \
-Once this criteria has been met, your PR receives the `lgtm/done` label. \
-From this point on, your only responsibility is to fix merge conflicts or respond to/implement requests by maintainers. \
-It is the responsibility of the maintainers from this point to get your PR merged.
-
-If a PR has the `lgtm/done` label and there are no open discussions or merge conflicts anymore, any maintainer can add the `reviewed/wait-merge` label. \
-This label means that the PR is part of the merge queue and will be merged as soon as possible. \
-The merge queue will be cleared in the order of the list below:
-
-<https://github.com/go-gitea/gitea/pulls?q=is%3Apr+label%3Areviewed%2Fwait-merge+sort%3Acreated-asc+is%3Aopen>
-
-Gitea uses it's own tool, the <https://github.com/GiteaBot/gitea-backporter> to automate parts of the review process. \
-This tool does the things listed below automatically:
-
-- create a backport PR if needed once the initial PR was merged
-- remove the PR from the merge queue after the PR merged
-- keep the oldest branch in the merge queue up to date with merges
-
-### Final call
-
-If a PR has been ignored for more than 7 days with no comments or reviews, and the author or any maintainer believes it will not survive a long wait (such as a refactoring PR), they can send "final call" to the TOC by mentioning them in a comment.
-
-After another 7 days, if there is still zero approval, this is considered a polite refusal, and the PR will be closed to avoid wasting further time. Therefore, the "final call" has a cost, and should be used cautiously.
-
-However, if there are no objections from maintainers, the PR can be merged with only one approval from the TOC (not the author).
-
-### Commit messages
-
-Mergers are able and required to rewrite the PR title and summary (the first comment of a PR) so that it can produce an easily understandable commit message if necessary. \
-The final commit message should no longer contain any uncertainty such as `hopefully, <x> won't happen anymore`. Replace uncertainty with certainty.
-
-#### PR Co-authors
-
-A person counts as a PR co-author the moment they (co-)authored a commit that is not simply a `Merge base branch into branch` commit. \
-Mergers are required to remove such "false-positive" co-authors when writing the commit message. \
-The true co-authors must remain in the commit message.
-
-#### PRs targeting `main`
-
-The commit message of PRs targeting `main` is always
-
-```bash
-$PR_TITLE ($PR_INDEX)
-
-$REWRITTEN_PR_SUMMARY
+<div class="gt-name1 gt-name2 {{if .IsFoo}}gt-foo{{end}}" {{if .IsFoo}}data-foo{{end}}></div>
 ```
 
-#### Backport PRs
-
-The commit message of backport PRs is always
-
-```bash
-$PR_TITLE ($INITIAL_PR_INDEX) ($BACKPORT_PR_INDEX)
-
-$REWRITTEN_PR_SUMMARY
+```
+<div class="gt-name1 gt-name2{{if .IsFoo}} gt-foo{{end}}"{{if .IsFoo}} data-foo{{end}}></div>
 ```
 
-## Documentation
-
-If you add a new feature or change an existing aspect of Gitea, the documentation for that feature must be created or updated in the same PR.
-
-## API v1
+to make the code more readable.
 
-The API is documented by [swagger](http://try.gitea.io/api/swagger) and is based on [the GitHub API](https://docs.github.com/en/rest).
+### Vue3 and JSX
 
-### GitHub API compatibility
+Gitea is using `Vue3` now. We decided not to introduce `JSX` to keep the HTML and JavaScript code separated.
 
-Gitea's API should use the same endpoints and fields as the GitHub API as far as possible, unless there are good reasons to deviate. \
-If Gitea provides functionality that GitHub does not, a new endpoint can be created. \
-If information is provided by Gitea that is not provided by the GitHub API, a new field can be used that doesn't collide with any GitHub fields. \
-Updating an existing API should not remove existing fields unless there is a really good reason to do so. \
-The same applies to status responses. If you notice a problem, feel free to leave a comment in the code for future refactoring to API v2 (which is currently not planned).
+### UI Examples
 
-### Adding/Maintaining API routes
+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`.
 
-All expected results (errors, success, fail messages) must be documented ([example](https://github.com/go-gitea/gitea/blob/c620eb5b2d0d874da68ebd734d3864c5224f71f7/routers/api/v1/repo/issue.go#L319-L327)). \
-All JSON input types must be defined as a struct in [modules/structs/](modules/structs/) ([example](https://github.com/go-gitea/gitea/blob/c620eb5b2d0d874da68ebd734d3864c5224f71f7/modules/structs/issue.go#L76-L91)) \
-and referenced in [routers/api/v1/swagger/options.go](https://github.com/go-gitea/gitea/blob/c620eb5b2d0d874da68ebd734d3864c5224f71f7/routers/api/v1/swagger/options.go). \
-They can then be used like [this example](https://github.com/go-gitea/gitea/blob/c620eb5b2d0d874da68ebd734d3864c5224f71f7/routers/api/v1/repo/issue.go#L318). \
-All JSON responses must be defined as a struct in [modules/structs/](modules/structs/) ([example](https://github.com/go-gitea/gitea/blob/c620eb5b2d0d874da68ebd734d3864c5224f71f7/modules/structs/issue.go#L36-L68)) \
-and referenced in its category in [routers/api/v1/swagger/](routers/api/v1/swagger/) ([example](https://github.com/go-gitea/gitea/blob/c620eb5b2d0d874da68ebd734d3864c5224f71f7/routers/api/v1/swagger/issue.go#L11-L16)) \
-They can be used like [this example](https://github.com/go-gitea/gitea/blob/c620eb5b2d0d874da68ebd734d3864c5224f71f7/routers/api/v1/repo/issue.go#L277-L279).
+## Styleguide
 
-### When to use what HTTP method
+You should always run `make fmt` before committing to conform to Gitea's styleguide.
 
-In general, HTTP methods are chosen as follows:
+## Testing
 
-- **GET** endpoints return the requested object(s) and status **OK (200)**
-- **DELETE** endpoints return the status **No Content (204)** and no content either
-- **POST** endpoints are used to **create** new objects (e.g. a User) and return the status **Created (201)** and the created object
-- **PUT** endpoints are used to **add/assign** existing Objects (e.g. a user to a team) and return the status **No Content (204)** and no content either
-- **PATCH** endpoints are used to **edit/change** an existing object and return the changed object and the status **OK (200)**
+Before submitting a pull request, run all tests to make sure your changes don't cause a regression elsewhere.
 
-### Requirements for API routes
+Here's how to run the test suite:
 
-All parameters of endpoints changing/editing an object must be optional (except the ones to identify the object, which are required).
+- code lint
 
-Endpoints returning lists must
+|                       |                                                                   |
+| :-------------------- | :---------------------------------------------------------------- |
+|``make lint``          | lint everything (not needed if you only change the front- **or** backend)    |
+|``make lint-frontend`` | lint frontend files  |
+|``make lint-backend``  | lint backend files   |
 
-- support pagination (`page` & `limit` options in query)
-- set `X-Total-Count` header via **SetTotalCountHeader** ([example](https://github.com/go-gitea/gitea/blob/7aae98cc5d4113f1e9918b7ee7dd09f67c189e3e/routers/api/v1/repo/issue.go#L444))
+- run tests (we suggest running them on Linux)
 
-## Backports and Frontports
+|  Command                               | Action                                           |              |
+| :------------------------------------- | :----------------------------------------------- | ------------ |
+|``make test[\#SpecificTestName]``       |  run unit test(s)  | |
+|``make test-sqlite[\#SpecificTestName]``|  run [integration](tests/integration) test(s) for SQLite |[More details](tests/integration/README.md)  |
+|``make test-e2e-sqlite[\#SpecificTestName]``|  run [end-to-end](tests/e2e) test(s) for SQLite |[More details](tests/e2e/README.md)  |
 
-### What is backported?
+# PRs
 
-We backport PRs given the following circumstances:
+Always open PRs with any changes and do not merge directly into main.
 
-1. Feature freeze is active, but `<version>-rc0` has not been released yet. Here, we backport as much as possible. <!-- TODO: Is that our definition with the new backport bot? -->
-2. `rc0` has been released. Here, we only backport bug- and security-fixes, and small enhancements. Large PRs such as refactors are not backported anymore. <!-- TODO: Is that our definition with the new backport bot? -->
-3. We never backport new features.
-4. We never backport breaking changes except when
-    1. The breaking change has no effect on the vast majority of users
-    2. The component triggering the breaking change is marked as experimental
+## General Guidelines for GitHub
 
-### How to backport?
+1. Write clear and meaningful commit messages.
 
-In the past, it was necessary to manually backport your PRs. \
-Now, that's not a requirement anymore as our [backport bot](https://github.com/GiteaBot) tries to create backports automatically once the PR is merged when the PR
+2. Use “atomic commits” -- atomic commits are small, focused commits that address a single, cohesive change. Rationale: Atomic commits provide a clear, granular, and efficient history, facilitating collaboration, bug identification, and integration with CI/CD pipelines.
 
-- does not have the label `backport/manual`
-- has the label `backport/<version>`
+3. Ensure development is completed on dedicated feature branches -- never push changes directly to main. Rationale: Required to keep main stable.
 
-The `backport/manual` label signifies either that you want to backport the change yourself, or that there were conflicts when backporting, thus you **must** do it yourself.
+4. Always pull the latest changes prior to pushing changes. Rationale: Minimizes the risk of conflicts.
 
-### Format of backport PRs
+5. Do not version user-specific settings and configurations (which may not be relevant or compatible across different developers or environments), temporary files, data files, or any files that can be generated from the source code.  Use a .gitignore file to specify file patterns that should be ignored. Rationale: Keeps the repo clean and focused.
 
-The title of backport PRs should be
+6. Please avoid making changes to the commit history after the pull request is opened.
 
-```
-<original PR title> (#<original pr number>)
-```
+7. Merge is best used when the target branch is supposed to be shared. Rebase is best used when the target branch is private.
 
-The first two lines of the summary of the backporting PR should be
+## Guidelines for Pull Requests (PRs)
 
-```
-Backport #<original pr number>
+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.
 
-with the rest of the summary and labels matching the original PR.
+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.
 
-### Frontports
+Before submitting a pull request, ensure that most or all of the following criteria are met:
 
-Frontports behave exactly as described above for backports.
+- [ ] Title is descriptive
 
-## Developer Certificate of Origin (DCO)
+- [ ] Detailed description of the changes made in the PR
 
-We consider the act of contributing to the code by submitting a Pull Request as the "Sign off" or agreement to the certifications and terms of the [DCO](DCO) and [MIT license](LICENSE). \
-No further action is required. \
-You can also decide to sign off your commits by adding the following line at the end of your commit messages:
+- [ ] If there is a specific issue then it is referenced in the description (eg. "Closes," "Fixes," or "Resolves" issue X)
 
-```
-Signed-off-by: Joe Smith <joe.smith@email.com>
-```
+- [ ] Feature branch is up-to-date with target branch by regular rebasing
 
-If you set the `user.name` and `user.email` Git config options, you can add the line to the end of your commits automatically with `git commit -s`.
+- [ ] Extensive testing was run before opening PR
 
-We assume in good faith that the information you provide is legally binding.
+- [ ] No merge conflicts
 
-## Release Cycle
+## Guidelines for Pull Request Comments
 
-We adopted a release schedule to streamline the process of working on, finishing, and issuing releases. \
-The overall goal is to make a major release every three or four months, which breaks down into two or three months of general development followed by one month of testing and polishing known as the release freeze. \
-All the feature pull requests should be
-merged before feature freeze. All feature pull requests haven't been merged before this feature freeze will be moved to next milestone, please notice our feature freeze announcement on discord. And, during the frozen period, a corresponding
-release branch is open for fixes backported from main branch. Release candidates
-are made during this period for user testing to
-obtain a final version that is maintained in this branch.
+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.
 
-During a development cycle, we may also publish any necessary minor releases
-for the previous version. For example, if the latest, published release is
-v1.2, then minor changes for the previous release—e.g., v1.1.0 -> v1.1.1—are
-still possible.
+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.
 
-## Maintainers
+## Exemplar Pull Request
 
-To make sure every PR is checked, we have [maintainers](MAINTAINERS). \
-Every PR **must** be reviewed by at least two maintainers (or owners) before it can get merged. \
-For refactoring PRs after a week and documentation only PRs, the approval of only one maintainer is enough. \
-A maintainer should be a contributor of Gitea and contributed at least
-4 accepted PRs. A contributor should apply as a maintainer in the
-[Discord](https://discord.gg/Gitea) `#develop` channel. The team maintainers may invite the contributor. A maintainer
-should spend some time on code reviews. If a maintainer has no
-time to do that, they should apply to leave the maintainers team
-and we will give them the honor of being a member of the [advisors
-team](https://github.com/orgs/go-gitea/teams/advisors). Of course, if
-an advisor has time to code review, we will gladly welcome them back
-to the maintainers team. If a maintainer is inactive for more than 3
-months and forgets to leave the maintainers team, the owners may move
-him or her from the maintainers team to the advisors team.
-For security reasons, Maintainers should use 2FA for their accounts and
-if possible provide GPG signed commits.
-https://help.github.com/articles/securing-your-account-with-two-factor-authentication-2fa/
-https://help.github.com/articles/signing-commits-with-gpg/
+<img width="800" alt="image" src="https://github.com/user-attachments/assets/0882bdaf-ecd0-4024-b7c9-dc60edd3c91c">
 
-Furthermore, any account with write access (like bots and TOC members) **must** use 2FA.
-https://help.github.com/articles/securing-your-account-with-two-factor-authentication-2fa/
+### Building continuously
 
-## Technical Oversight Committee (TOC)
+To run and continuously rebuild when source files change:
 
-At the start of 2023, the `Owners` team was dissolved. Instead, the governance charter proposed a technical oversight committee (TOC) which expands the ownership team of the Gitea project from three elected positions to six positions. Three positions are elected as it has been over the past years, and the other three consist of appointed members from the Gitea company.
-https://blog.gitea.com/quarterly-23q1/
-
-### TOC election process
-
-Any maintainer is eligible to be part of the community TOC if they are not associated with the Gitea company.
-A maintainer can either nominate themselves, or can be nominated by other maintainers to be a candidate for the TOC election.
-If you are nominated by someone else, you must first accept your nomination before the vote starts to be a candidate.
-
-The TOC is elected for one year, the TOC election happens yearly.
-After the announcement of the results of the TOC election, elected members have two weeks time to confirm or refuse the seat.
-If an elected member does not answer within this timeframe, they are automatically assumed to refuse the seat.
-Refusals result in the person with the next highest vote getting the same choice.
-As long as seats are empty in the TOC, members of the previous TOC can fill them until an elected member accepts the seat.
-
-If an elected member that accepts the seat does not have 2FA configured yet, they will be temporarily counted as `answer pending` until they manage to configure 2FA, thus leaving their seat empty for this duration.
-
-### Current TOC members
-
-- 2024-01-01 ~ 2024-12-31
-  - Company
-    - [Jason Song](https://gitea.com/wolfogre) <i@wolfogre.com>
-    - [Lunny Xiao](https://gitea.com/lunny) <xiaolunwen@gmail.com>
-    - [Matti Ranta](https://gitea.com/techknowlogick) <techknowlogick@gitea.com>
-  - Community
-    - [6543](https://gitea.com/6543) <6543@obermui.de>
-    - [delvh](https://gitea.com/delvh) <dev.lh@web.de>
-    - [John Olheiser](https://gitea.com/jolheiser) <john.olheiser@gmail.com>
-
-### Previous TOC/owners members
-
-Here's the history of the owners and the time they served:
-
-- [Lunny Xiao](https://gitea.com/lunny) - 2016, 2017, [2018](https://github.com/go-gitea/gitea/issues/3255), [2019](https://github.com/go-gitea/gitea/issues/5572), [2020](https://github.com/go-gitea/gitea/issues/9230), [2021](https://github.com/go-gitea/gitea/issues/13801), [2022](https://github.com/go-gitea/gitea/issues/17872), 2023
-- [Kim Carlbäcker](https://github.com/bkcsoft) - 2016, 2017
-- [Thomas Boerger](https://gitea.com/tboerger) - 2016, 2017
-- [Lauris Bukšis-Haberkorns](https://gitea.com/lafriks) - [2018](https://github.com/go-gitea/gitea/issues/3255), [2019](https://github.com/go-gitea/gitea/issues/5572), [2020](https://github.com/go-gitea/gitea/issues/9230), [2021](https://github.com/go-gitea/gitea/issues/13801)
-- [Matti Ranta](https://gitea.com/techknowlogick) - [2019](https://github.com/go-gitea/gitea/issues/5572), [2020](https://github.com/go-gitea/gitea/issues/9230), [2021](https://github.com/go-gitea/gitea/issues/13801), [2022](https://github.com/go-gitea/gitea/issues/17872), 2023
-- [Andrew Thornton](https://gitea.com/zeripath) - [2020](https://github.com/go-gitea/gitea/issues/9230), [2021](https://github.com/go-gitea/gitea/issues/13801), [2022](https://github.com/go-gitea/gitea/issues/17872), 2023
-- [6543](https://gitea.com/6543) - 2023
-- [John Olheiser](https://gitea.com/jolheiser) - 2023
-- [Jason Song](https://gitea.com/wolfogre) - 2023
-
-## Governance Compensation
-
-Each member of the community elected TOC will be granted $500 each month as compensation for their work.
-
-Furthermore, any community release manager for a specific release or LTS will be compensated $500 for the delivery of said release.
-
-These funds will come from community sources like the OpenCollective rather than directly from the company.
-Only non-company members are eligible for this compensation, and if a member of the community TOC takes the responsibility of release manager, they would only be compensated for their TOC duties.
-Gitea Ltd employees are not eligible to receive any funds from the OpenCollective unless it is reimbursement for a purchase made for the Gitea project itself.
-
-## TOC & Working groups
-
-With Gitea covering many projects outside of the main repository, several groups will be created to help focus on specific areas instead of requiring maintainers to be a jack-of-all-trades. Maintainers are of course more than welcome to be part of multiple groups should they wish to contribute in multiple places.
-
-The currently proposed groups are:
-
-- **Core Group**: maintain the primary Gitea repository
-- **Integration Group**: maintain the Gitea ecosystem's related tools, including go-sdk/tea/changelog/bots etc.
-- **Documentation Group**: maintain related documents and repositories
-- **Translation Group**: coordinate with translators and maintain translations
-- **Security Group**: managed by TOC directly, members are decided by TOC, maintains security patches/responsible for security items
-
-## Roadmap
-
-Each year a roadmap will be discussed with the entire Gitea maintainers team, and feedback will be solicited from various stakeholders.
-TOC members need to review the roadmap every year and work together on the direction of the project.
-
-When a vote is required for a proposal or other change, the vote of community elected TOC members count slightly more than the vote of company elected TOC members. With this approach, we both avoid ties and ensure that changes align with the mission statement and community opinion.
-
-You can visit our roadmap on the wiki.
-
-## Versions
-
-Gitea has the `main` branch as a tip branch and has version branches
-such as `release/v1.19`. `release/v1.19` is a release branch and we will
-tag `v1.19.0` for binary download. If `v1.19.0` has bugs, we will accept
-pull requests on the `release/v1.19` branch and publish a `v1.19.1` tag,
-after bringing the bug fix also to the main branch.
-
-Since the `main` branch is a tip version, if you wish to use Gitea
-in production, please download the latest release tag version. All the
-branches will be protected via GitHub, all the PRs to every branch must
-be reviewed by two maintainers and must pass the automatic tests.
+```
+# for both frontend and backend
+make watch
 
-## Releasing Gitea
+# or: watch frontend files (html/js/css) only
+make watch-frontend
 
-- Let $vmaj, $vmin and $vpat be Major, Minor and Patch version numbers, $vpat should be rc1, rc2, 0, 1, ...... $vmaj.$vmin will be kept the same as milestones on github or gitea in future.
-- Before releasing, confirm all the version's milestone issues or PRs has been resolved. Then discuss the release on Discord channel #maintainers and get agreed with almost all the owners and mergers. Or you can declare the version and if nobody against in about serval hours.
-- If this is a big version first you have to create PR for changelog on branch `main` with PRs with label `changelog` and after it has been merged do following steps:
-  - Create `-dev` tag as `git tag -s -F release.notes v$vmaj.$vmin.0-dev` and push the tag as `git push origin v$vmaj.$vmin.0-dev`.
-  - When CI has finished building tag then you have to create a new branch named `release/v$vmaj.$vmin`
-- If it is bugfix version create PR for changelog on branch `release/v$vmaj.$vmin` and wait till it is reviewed and merged.
-- Add a tag as `git tag -s -F release.notes v$vmaj.$vmin.$`, release.notes file could be a temporary file to only include the changelog this version which you added to `CHANGELOG.md`.
-- And then push the tag as `git push origin v$vmaj.$vmin.$`. Drone CI will automatically create a release and upload all the compiled binary. (But currently it doesn't add the release notes automatically. Maybe we should fix that.)
-- If needed send a frontport PR for the changelog to branch `main` and update the version in `docs/config.yaml` to refer to the new version.
-- Send PR to [blog repository](https://gitea.com/gitea/blog) announcing the release.
-- Verify all release assets were correctly published through CI on dl.gitea.com and GitHub releases. Once ACKed:
-  - bump the version of https://dl.gitea.com/gitea/version.json
-  - merge the blog post PR
-  - announce the release in discord `#announcements`
+# or: watch backend files (go) only
+make watch-backend
+```
diff --git a/README.md b/README.md
index f57944917447..2aeb4f1ec703 100644
--- a/README.md
+++ b/README.md
@@ -1,140 +1,59 @@
-# Gitea
-
-[![](https://github.com/go-gitea/gitea/actions/workflows/release-nightly.yml/badge.svg?branch=main)](https://github.com/go-gitea/gitea/actions/workflows/release-nightly.yml?query=branch%3Amain "Release Nightly")
-[![](https://img.shields.io/discord/322538954119184384.svg?logo=discord&logoColor=white&label=Discord&color=5865F2)](https://discord.gg/Gitea "Join the Discord chat at https://discord.gg/Gitea")
-[![](https://goreportcard.com/badge/code.gitea.io/gitea)](https://goreportcard.com/report/code.gitea.io/gitea "Go Report Card")
-[![](https://pkg.go.dev/badge/code.gitea.io/gitea?status.svg)](https://pkg.go.dev/code.gitea.io/gitea "GoDoc")
-[![](https://img.shields.io/github/release/go-gitea/gitea.svg)](https://github.com/go-gitea/gitea/releases/latest "GitHub release")
-[![](https://www.codetriage.com/go-gitea/gitea/badges/users.svg)](https://www.codetriage.com/go-gitea/gitea "Help Contribute to Open Source")
-[![](https://opencollective.com/gitea/tiers/backers/badge.svg?label=backers&color=brightgreen)](https://opencollective.com/gitea "Become a backer/sponsor of gitea")
-[![](https://img.shields.io/badge/License-MIT-blue.svg)](https://opensource.org/licenses/MIT "License: MIT")
-[![Contribute with Gitpod](https://img.shields.io/badge/Contribute%20with-Gitpod-908a85?logo=gitpod)](https://gitpod.io/#https://github.com/go-gitea/gitea)
-[![](https://badges.crowdin.net/gitea/localized.svg)](https://crowdin.com/project/gitea "Crowdin")
-[![](https://badgen.net/https/api.tickgit.com/badgen/github.com/go-gitea/gitea/main)](https://www.tickgit.com/browse?repo=github.com/go-gitea/gitea&branch=main "TODOs")
-
-[View this document in Chinese](./README_ZH.md)
+# RIA Hub
 
 ## Purpose
 
-The goal of this project is to make the easiest, fastest, and most
-painless way of setting up a self-hosted Git service.
+Radio Intelligence Apps Hub (RIA Hub) by Qoherent is an AI development platform for software-defined radios, designed for radio signal processing engineers and researchers in wireless technologies. RIA accelerates intelligent radio development by significantly reducing integration between stages, allowing a sharper focus on innovation. The platform streamlines dataset creation, algorithm design, and model deployment, enhancing productivity and reducing project timelines. Built on a foundation of open-source accessibility, a comprehensive IP library, and automation capabilities, RIA drives the creation of intelligent radios, unlocking solutions in an increasingly congested and challenged wireless spectrum.
 
-As Gitea is written in Go, it works across **all** the platforms and
-architectures that are supported by Go, including Linux, macOS, and
-Windows on x86, amd64, ARM and PowerPC architectures.
-This project has been
-[forked](https://blog.gitea.com/welcome-to-gitea/) from
-[Gogs](https://gogs.io) since November of 2016, but a lot has changed.
+RIA Hub is built on top of [Gitea](https://github.com/go-gitea/gitea) and the [RIA Project](https://github.com/qoherent/ria).
 
-For online demonstrations, you can visit [try.gitea.io](https://try.gitea.io).
+## Getting Started
 
-For accessing free Gitea service (with a limited number of repositories), you can visit [gitea.com](https://gitea.com/user/login).
+You should [install go](https://golang.org/doc/install) and set up your go environment correctly (version 1.22).
 
-To quickly deploy your own dedicated Gitea instance on Gitea Cloud, you can start a free trial at [cloud.gitea.com](https://cloud.gitea.com).
+Next, [install Node.js with npm](https://nodejs.org/en/download/package-manager) which is required to build the JavaScript and CSS files. The minimum supported Node.js version is 18 and the latest LTS version is recommended.
 
-## Building
+To lint the template files, ensure [Python](https://www.python.org/) and [Poetry](https://python-poetry.org/) are installed.
 
-From the root of the source tree, run:
+RIA Hub makes heavy use of Make to automate tasks and improve development.
 
-    TAGS="bindata" make build
+To install on linux for Debian based distributions (like Ubuntu): `sudo apt-get install make`.
 
-or if SQLite support is required:
+For RPM based distributions like CentOS: `sudo yum install make`.
 
-    TAGS="bindata sqlite sqlite_unlock_notify" make build
+For windows machines, you can directly download Make for Windows [here](https://gnuwin32.sourceforge.net/packages/make.htm), or simply use a package manager like [Chocolatey](https://chocolatey.org/install) and run `choco install make`.
 
-The `build` target is split into two sub-targets:
+For MacOS, this is easy to do using xcode. Simply run `xcode-select --install` and in the pop up window, click `Install`, and agree to the Terms of Service.
 
-- `make backend` which requires [Go Stable](https://go.dev/dl/), the required version is defined in [go.mod](/go.mod).
-- `make frontend` which requires [Node.js LTS](https://nodejs.org/en/download/) or greater.
+Once everything is installed, download and clone the RIA Hub source code and cd into it:
 
-Internet connectivity is required to download the go and npm modules. When building from the official source tarballs which include pre-built frontend files, the `frontend` target will not be triggered, making it possible to build without Node.js.
+`git clone https://github.com/qoherent/ria-hub.git`
 
-More info: https://docs.gitea.com/installation/install-from-source
+`cd ria-hub`
 
-## Using
+Building RIA Hub
 
-    ./gitea web
+When you have a clone of RIA Hub, you can create an executable build from source using:
 
-> [!NOTE]
-> If you're interested in using our APIs, we have experimental support with [documentation](https://try.gitea.io/api/swagger).
+`TAGS="bindata sqlite sqlite_unlock_notify" make build`
 
-## Contributing
+The build target will execute both the frontend and backend sub-targets. If the bindata tag is present, the frontend files will be compiled into the binary.
 
-Expected workflow is: Fork -> Patch -> Push -> Pull Request
+To create a web server run `./gitea web` and your local instance will be available on `localhost:3000`.
 
-> [!NOTE]
->
-> 1. **YOU MUST READ THE [CONTRIBUTORS GUIDE](CONTRIBUTING.md) BEFORE STARTING TO WORK ON A PULL REQUEST.**
-> 2. If you have found a vulnerability in the project, please write privately to **security@gitea.io**. Thanks!
+The first time you build, you will be at the setup screen. Here, you need to configure database settings. The only change you need to make here is choosing SQLite3 for a quick and easy installation. You can view the other settings and change them as required, then hit the submit button at the bottom.
 
-## Translating
+Once you create and set up your instance, you need to configure the `app.ini` file found in `custom/conf/`.
 
-Translations are done through Crowdin. If you want to translate to a new language ask one of the managers in the Crowdin project to add a new language there.
+Note: You need to do this **_after_** building and configuring RIA Hub at least once. The `app.ini` file is propagated and shows up when you set up your local instance for the first time.
 
-You can also just create an issue for adding a language or ask on discord on the #translation channel. If you need context or find some translation issues, you can leave a comment on the string or ask on Discord. For general translation questions there is a section in the docs. Currently a bit empty but we hope to fill it as questions pop up.
+Add the following snippet to the file:
 
-https://docs.gitea.com/contributing/localization
+```
+[ui]
+DEFAULT_THEME = qoherent-theme
+THEMES = qoherent-theme
+```
 
-[![Crowdin](https://badges.crowdin.net/gitea/localized.svg)](https://crowdin.com/project/gitea)
+Once done, rebuild your instance. Log in to the account you created earlier (this is the admin account for this instance), navigate to settings > appearance and under default theme, select `qoherent-theme`.
 
-## Further information
-
-For more information and instructions about how to install Gitea, please look at our [documentation](https://docs.gitea.com/).
-If you have questions that are not covered by the documentation, you can get in contact with us on our [Discord server](https://discord.gg/Gitea) or create  a post in the [discourse forum](https://discourse.gitea.io/).
-
-We maintain a list of Gitea-related projects at [gitea/awesome-gitea](https://gitea.com/gitea/awesome-gitea).
-
-The official Gitea CLI is developed at [gitea/tea](https://gitea.com/gitea/tea).
-
-## Authors
-
-- [Maintainers](https://github.com/orgs/go-gitea/people)
-- [Contributors](https://github.com/go-gitea/gitea/graphs/contributors)
-- [Translators](options/locale/TRANSLATORS)
-
-## Backers
-
-Thank you to all our backers! 🙏 [[Become a backer](https://opencollective.com/gitea#backer)]
-
-<a href="https://opencollective.com/gitea#backers" target="_blank"><img src="https://opencollective.com/gitea/backers.svg?width=890"></a>
-
-## Sponsors
-
-Support this project by becoming a sponsor. Your logo will show up here with a link to your website. [[Become a sponsor](https://opencollective.com/gitea#sponsor)]
-
-<a href="https://opencollective.com/gitea/sponsor/0/website" target="_blank"><img src="https://opencollective.com/gitea/sponsor/0/avatar.svg"></a>
-<a href="https://opencollective.com/gitea/sponsor/1/website" target="_blank"><img src="https://opencollective.com/gitea/sponsor/1/avatar.svg"></a>
-<a href="https://opencollective.com/gitea/sponsor/2/website" target="_blank"><img src="https://opencollective.com/gitea/sponsor/2/avatar.svg"></a>
-<a href="https://opencollective.com/gitea/sponsor/3/website" target="_blank"><img src="https://opencollective.com/gitea/sponsor/3/avatar.svg"></a>
-<a href="https://opencollective.com/gitea/sponsor/4/website" target="_blank"><img src="https://opencollective.com/gitea/sponsor/4/avatar.svg"></a>
-<a href="https://opencollective.com/gitea/sponsor/5/website" target="_blank"><img src="https://opencollective.com/gitea/sponsor/5/avatar.svg"></a>
-<a href="https://opencollective.com/gitea/sponsor/6/website" target="_blank"><img src="https://opencollective.com/gitea/sponsor/6/avatar.svg"></a>
-<a href="https://opencollective.com/gitea/sponsor/7/website" target="_blank"><img src="https://opencollective.com/gitea/sponsor/7/avatar.svg"></a>
-<a href="https://opencollective.com/gitea/sponsor/8/website" target="_blank"><img src="https://opencollective.com/gitea/sponsor/8/avatar.svg"></a>
-<a href="https://opencollective.com/gitea/sponsor/9/website" target="_blank"><img src="https://opencollective.com/gitea/sponsor/9/avatar.svg"></a>
-
-## FAQ
-
-**How do you pronounce Gitea?**
-
-Gitea is pronounced [/ɡɪ’ti:/](https://youtu.be/EM71-2uDAoY) as in "gi-tea" with a hard g.
-
-**Why is this not hosted on a Gitea instance?**
-
-We're [working on it](https://github.com/go-gitea/gitea/issues/1029).
-
-## License
-
-This project is licensed under the MIT License.
-See the [LICENSE](https://github.com/go-gitea/gitea/blob/main/LICENSE) file
-for the full license text.
-
-## Screenshots
-
-Looking for an overview of the interface? Check it out!
-
-|![Dashboard](https://dl.gitea.com/screenshots/home_timeline.png)|![User Profile](https://dl.gitea.com/screenshots/user_profile.png)|![Global Issues](https://dl.gitea.com/screenshots/global_issues.png)|
-|:---:|:---:|:---:|
-|![Branches](https://dl.gitea.com/screenshots/branches.png)|![Web Editor](https://dl.gitea.com/screenshots/web_editor.png)|![Activity](https://dl.gitea.com/screenshots/activity.png)|
-|![New Migration](https://dl.gitea.com/screenshots/migration.png)|![Migrating](https://dl.gitea.com/screenshots/migration.gif)|![Pull Request View](https://image.ibb.co/e02dSb/6.png)|
-|![Pull Request Dark](https://dl.gitea.com/screenshots/pull_requests_dark.png)|![Diff Review Dark](https://dl.gitea.com/screenshots/review_dark.png)|![Diff Dark](https://dl.gitea.com/screenshots/diff_dark.png)|
+<img width="1470" alt="Screenshot 2024-04-15 at 11 49 58 AM" src="https://github.com/user-attachments/assets/c51deee7-bb8e-44e2-9860-9c9778fd3159">