docs: Add docs for PgM, user support, and documenation

CONTRIBUTING.md

@@ -6,9 +6,8 @@ Contributions generally fall in to one of several different categories, each of
 
 - [Translations](/docs/contributing/translate.md)
 - [Code](/docs/contributing/code.md)
-- Documentation (details coming mid-September 2023)
+- [Documentation](/docs/contributing/documentation.md)
-- Project Management (details coming mid-September 2023)
+- [Project Management](/docs/contributing/project-management.md)
-- User support  (details coming mid-September 2023)
+- [User support and social presence](/docs/contributing/user-support.md)
-- Social presence (details coming mid-September 2023)
 
 If you have any questions please join one of the [discussions](https://github.com/pachli/pachli-android/discussions)

docs/contributing/documentation.md

@@ -0,0 +1,50 @@
+# Contributing to documentation
+
+> [!NOTE]
+> These instructions are supposed to be complete and accurate. If anything is unclear or does not work please report it so it can be fixed.
+
+## Synopsis
+
+Thank you for wanting to improve Pachli by contributing documentation skills.
+
+After reading this document you will know:
+
+- Specific areas to focus on that would bring immediate benefit
+
+## Overview and activities
+
+### Writing contributor documentation
+
+[pachli-android/docs](https://github.com/pachli/pachli-android/tree/main/docs) contains the documentation for project contributors (you're reading some of it now).
+
+This changes slowly over time, but may be incomplete or out of date.
+
+These documents are generally either [How-to guides](https://diataxis.fr/how-to-guides/) or [explanations](https://diataxis.fr/explanation/).
+
+### Writing in-app documentation
+
+The app contains some "documentation", which will grow over time.
+
+Most of this is short messages, labels in the UI, brief descriptions of preference settings, and so on.
+
+However, some of it is longer text, and the amount of that will increase as the UI changes to show more hints on first-use to new users.
+
+### Writing website content
+
+https://pachli.app is the project's web presence. Its contents are a mix of:
+
+- [How-to guides](https://diataxis.fr/how-to-guides/), such as https://pachli.app/download/
+- [Explanations](https://diataxis.fr/explanation/), such as https://pachli.app/about/
+- Blog posts
+  - One for each release
+  - Others as necessary
+
+The website repository is https://github.com/pachli/website
+
+## Technology
+
+**Contributor documentation** is generally written in [GitHub flavoured Markdown](https://github.github.com/gfm/).
+
+**In-app documentation** is generally written as [Android resource strings](https://developer.android.com/guide/topics/resources/string-resource). E.g., see [app/src/main/res/values/strings.xml](https://github.com/pachli/pachli-android/blob/main/app/src/main/res/values/strings.xml). Familiarity with Android resource strings (e.g., how placeholders are written, how to manage strings with different plural forms) is beneficial, but not mandatory.
+
+**Website content** is managed using [Jekyll](https://jekyllrb.com/) and written in [GitHub flavoured Markdown](https://github.github.com/gfm/).

docs/contributing/project-management.md

@@ -0,0 +1,71 @@
+# Contributing to project management
+
+> [!NOTE]
+> These instructions are supposed to be complete and accurate. If anything is unclear or does not work please report it so it can be fixed.
+
+## Synopsis
+
+Thank you for wanting to improve Pachli by contributing project management skills.
+
+After reading this document you will know:
+
+- Specific areas to focus on that would bring immediate benefit
+
+## Overview
+
+Project management is difficult at the best of times, and an open source project relying primarily on volunteer work is not the best of times.
+
+## Activities
+
+With that in mind the following list describes specific activities that are typically part of a project manager's role and would be useful ways to onboard on to the project before making a larger commitment.
+
+This is not an exhaustive list. If there are other ways that you would like to contribute and they are not listed here please start a [discussion](https://github.com/pachli/pachli-android/discussions).
+
+> [!NOTE]
+> Each of the following has an implicit "... and describe your processes so other volunteers can help, and automate the work where possible" step.
+
+### Curating the list of open issues
+
+Left untended open bug reports and feature requests can grow without bounds. Activites to help include:
+
+- Follow up on incomplete bug reports to get more information from the reporter
+  - Device, server, relevant accounts, screnshots, etc
+- Make sure that bug reports are not being ignored
+- Identify and close duplicate reports
+- Apply consistent bug report labels to make them easy to manage
+
+### Create new issues from user feedback
+
+- Create GitHub issues to track problems or feature requests reported by users to the @pachli account or the #pachli hashtag
+
+### Project prioritisation and planning
+
+As an open source project contributors are free to work on whichever issues they prefer.
+
+However, providing clear guidance about the relative priority of different issues can still be extremely helpful. Contributors may prefer to work on issues they know affect many people, or have a large impact on the affected users.
+
+Mining issue reports to extract common themes or frustrations, developing and proposing a prioritisation scheme, and using it within the project could be extremely helpful.
+
+### Follow up on open-but-stalled PRs
+
+A contributor might start a PR and then the work stalls. It is very helpful to identify stalled PRs, and help the work continue.
+
+- Had the submitter run out of time?
+  - Can someone else from the project finish the work?
+- Did they not understand the review feedback?
+  - Can the reviewer update the feedback?
+- Were they waiting for review and the project had not noticed?
+  - Determine who should review the PR, and ask them to assign it to themselves
+
+### Project internal communication
+
+- Communicate the state of ongoing activities to the rest of the project contributors
+- Track requests for comments on proposal documents
+
+### Liaise between the project and other Fediverse projects
+
+The project needs to keep track of new features planned for release in upcoming versions of Mastodon to determine how and when to support those features.
+
+Keeping track of features in other Mastodon-like software is also important; both as they get feature parity with Mastodon, and where they have features Mastodon doesn't but we should consider supporting.
+
+The project often discovers bugs in implementation of those features (or documentation thereof), reporting and tracking those is also very helpful.

docs/contributing/user-support.md

@@ -0,0 +1,27 @@
+# Contributing to user support and social presence
+
+> [!NOTE]
+> These instructions are supposed to be complete and accurate. If anything is unclear or does not work please report it so it can be fixed.
+
+## Synopsis
+
+Users can post questions or problem reports to Mastodon, either mentioning the `@pachli@mastodon.social` account or using the `#pachli` hashtag.
+
+After reading this document you will know how to respond to these support requests.
+
+## Activities
+
+### Responding to questions
+
+- Answer the question.
+- If you observe repeated instances of this question it may point to a UX issue in the app. Consider filing an issue to capture the possible improvement.
+
+### Responding to problem reports
+
+- Check the [list of closed issues](https://github.com/pachli/pachli-android/issues?q=is%3Aissue+is%3Aclosed) to see if the problem has already been fixed and will be in the next release.
+  - If it has then let the user know.
+  - If the fix is in a deployed version of Pachli Current then suggest they try that and confirm the fix works for them.
+- Check the [list of open issues](https://github.com/pachli/pachli-android/issues?q=is%3Aopen+is%3Aissue) to see if the problem has already been reported
+  - If it has then let the user know (link to the issue), with a timeframe for the fix (if known)
+    - Ask if the user has any additional information that can be used to help resolve the issue, ask them to add it
+  - If it hasn't, ask the user to create an issue, or, if they can't do that, ask them for enough information so you can create the issue on their behalf