Merge pull request 'Add issue and pull request templates for Forgejo' (#7819) from mkljczk/pleroma:forgejo-templates into develop

Reviewed-on: https://git.pleroma.social/pleroma/pleroma/pulls/7819
Reviewed-by: Phantasm <phnt@noreply.git.pleroma.social>

.forgejo/issue_template/bug.yaml

@@ -0,0 +1,25 @@
+name: 'Bug report'
+about: 'Report a bug in Pleroma'
+body:
+- type: markdown
+  attributes:
+    value: |
+      ### Precheck
+
+      * For support use https://git.pleroma.social/pleroma/pleroma-support or [community channels](https://git.pleroma.social/pleroma/pleroma#community-channels).
+      * Please do a quick search to ensure no similar bug has been reported before. If the bug has not been addressed after 2 weeks, it's fine to bump it.
+      * Try to ensure that the bug is actually related to the Pleroma backend. For example, if a bug happens in Pleroma-FE but not in Mastodon-FE or mobile clients, it's likely that the bug should be filed in [Pleroma-FE](https://git.pleroma.social/pleroma/pleroma-fe/issues/new) repository.
+- type: textarea
+  id: environment
+  attributes:
+    label: Environment
+    value: |
+      * Installation type (OTP or From Source):
+      * Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): 
+      * Elixir version (`elixir -v` for from source installations, N/A for OTP):
+      * Operating system:
+      * PostgreSQL version (`psql -V`):
+- type: textarea
+  id: bug-description
+  attributes:
+    label: Bug description

.forgejo/pull_request_template.md

@@ -0,0 +1,13 @@
+### Checklist
+
+- [ ] Adding a changelog: In the `changelog.d` directory, create a file named `<code>.<type>`.
+
+<!--
+  `<code>` can be anything, but we recommend using a more or less unique identifier to avoid collisions, such as the branch name.
+
+  `<type>` can be `add`, `change`, `remove`, `fix`, `security` or `skip`. `skip` is only used if there is no user-visible change in the PR (for example, only editing comments in the code). Otherwise, choose a type that corresponds to your change.
+
+  In the file, write the changelog entry. For example, if a PR adds group functionality, we can create a file named `group.add` and write `Add group functionality` in it.
+
+  If one changelog entry is not enough, you may add more. But that might mean you can split it into two PRs. Only use more than one changelog entry if you really need to (for example, when one change in the code fix two different bugs, or when refactoring).
+-->