Mastodon
/
Tusky-App-Android
mirror of https://github.com/tuskyapp/Tusky
1
0
Fork 0
Code Issues Releases Wiki Activity

Updates and cleanup

This commit is contained in:
Tak! 2023-09-18 09:49:24 +02:00
parent 7912f0b4d4
commit da9ff14421
1 changed files with 7 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
CONTRIBUTING.md
View File

@ -26,7 +26,7 @@ You do not have to restrict yourself to just working on one of those issues, but
### Best practices for working on an issue
- Post a comment to the issue, saying that you plan on working on it
- Join the developer chat room, https://matrix.to/#/#Tusky-General:matrix.org,
- Join the [Tusky Matrix channel](https://matrix.to/#/#Tusky-General:matrix.org)
### Best practices for creating PRs
@ -37,10 +37,6 @@ You do not have to restrict yourself to just working on one of those issues, but
- Include before/after screenshots as PR comments if your PR changes the UI
- PR should pass lint and tests before sending for review
Other good practices include:
- Use the issue number as a prefix for your PR branch (i.e., if you're working on issue 1234, call the branch `1234-...`)
### Architecture
We try to follow the [Guide to app architecture](https://developer.android.com/topic/architecture).
@ -55,9 +51,9 @@ This is enforced on CI; new code must pass `ktlintCheck`
### Android Lint
Android Lint is run on PRs on CI to prevent problems, your code must pass `./gradlew lintGreenDebug`.
You can run Android Lint locally to check for potential problems: `./gradlew lintGreenDebug`.
The use of `@Suppress...` annotations to ignore lint issues in some areas of the code is allowed, but not encouraged. It is helpful if you pre-emptively explain in your PR why the lint issue can not be corrected.
The use of `@Suppress...` annotations to ignore lint issues in some areas of the code is allowed, but not encouraged. It is helpful if you preemptively explain in your PR why the lint issue can not be corrected.
### Text
All English text that will be visible to users must be put in `app/src/main/res/values/strings.xml` so it is translateable into other languages.
@ -96,21 +92,21 @@ Tusky is primarily a Mastodon client and aims to always support the newest Masto
2. Therefore, **issues are only ever self-assigned**.
3. Self-assigning an issue is a clear statement of “I will do the work necessary to resolve this issue. If I can not do that in reasonable time I will un-assign the issue”
3. Self-assigning an issue is a clear statement of “I will do the work necessary to resolve this issue. If I can not do that in reasonable time I will unassign the issue”
4. If you have assigned an issue to yourself you are expected to provide periodic updates to that issue, at least one update every 7 days. This is to ensure that the state of the work on the issue is clear to everyone else on the project.
4. If you have assigned an issue to yourself, please provide periodic updates to that issue. This is to ensure that the state of the work on the issue is clear to everyone else on the project.
a. The update may be a variation of “I have not been able to work on this”. That's OK. The important thing is that this is valuable information to convey to everyone else.
b. If a PR is associated with the issue then updates to the PR are treated as updates to the issue
5. It is OK if you have assigned an issue to yourself, and then discover that you are not able to complete it or provide useful updates. If that happens just un-assign the issue. You don't have to provide a justification for why you can't do it at this time. It's enough to let the rest of the team know that someone else will need to pick this up.
5. It is OK if you have assigned an issue to yourself and then discover that you are not able to complete it or provide useful updates. If that happens, just remove the assignment from the issue. You don't have to provide a justification for why you can't do it at this time -- it's enough to let the rest of the team know that someone else will need to pick this up.
6. If you are working on an issue and someone else needs to make a decision, `@` them into the issue, and add the `blocked` label so they can find it.
a. Per item (1) do not assign the issue to the person who needs to make the decision.
b. Being blocked waiting on a decision does not remove the requirement to provide an update every 7 days. If you are blocked the update is “Blocked, waiting on a decision from @whoever” or similar. Again, this is all about clearly communicating the state of the work to the rest of the team.
b. If you are blocked, please continue providing updates, even if the update is “Blocked, waiting on a decision from @whoever”, so that you continue communicating the state of the work to the rest of the team.
### Setting issue labels