mirrors/SchildiChat-android
1
0
Fork 0
mirror of https://github.com/SchildiChat/SchildiChat-android.git synced 2024-11-22 09:25:49 +03:00
Code Issues Projects Releases Packages Wiki Activity

Fix link

Browse source
This commit is contained in:
Benoit Marty 2022-05-04 17:14:51 +02:00
parent 480a60a655
commit fce1552349
1 changed files with 2 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
docs/pull_request.md
View file

@ -116,7 +116,7 @@ Review such PR is the same recipe than for PR from Dependabot
##### Sync analytics plan ##### Sync analytics plan
This tools imports any update in the analytics plan. See instruction in the PR itself to handle it. This tools imports any update in the analytics plan. See instruction in the PR itself to handle it.
More info can be found in the file [analytics.md] More info can be found in the file [analytics.md](./analytics.md)
## Reviewing PR ## Reviewing PR
@ -247,4 +247,4 @@ Also "Resolve conversation" should probably be hit by the creator of the convers
PR submitter is responsible of the incoming change. PR reviewers who approved the PR take a part of responsibility on the code which will land to develop, and then be used by our users, and the user of our forks. PR submitter is responsible of the incoming change. PR reviewers who approved the PR take a part of responsibility on the code which will land to develop, and then be used by our users, and the user of our forks.
That said, bug may still be merged on `develop`, this is still acceptable of course. In this case, please make sure an issue is created and correctly labelled. Ideally, such issues should be fixed before the next release candidate, i.e. with a higher priority. But as we release the application every 10 working days, it can be hard to fix every bugs. That's why PR should be fully tested and reviewed before being merge and we should never comment code review remark with "will be handled later", or similar comments. That said, bug may still be merged on `develop`, this is still acceptable of course. In this case, please make sure an issue is created and correctly labelled. Ideally, such issues should be fixed before the next release candidate, i.e. with a higher priority. But as we release the application every 10 working days, it can be hard to fix every bugs. That's why PR should be fully tested and reviewed before being merge and we should never comment code review remark with "will be handled later", or similar comments.