Update ways of working

README.md

@@ -34,9 +34,12 @@ Please note that the `master` branch reflects ongoing development and is not pro
 * ODK developer Slack chat: [https://slack.getodk.org](https://slack.getodk.org)
 
 ## Release cycle
-Releases can be requested by any community member and generally happen every 2 months.
 
-Before release we perform a "code freeze" (we stop merging pull requests). A new beta will then be released to the Play Store by [@lognaturel](https://github.com/lognaturel) and that will be used for regression testing by [@getodk/testers](https://github.com/orgs/getodk/teams/testers). If any problems are found, the release is blocked until we can merge fixes. Regression testing should continue on the original beta build (rather than a new one with fixes) unless problems block the rest of testing. Once the process is complete, [@lognaturel](https://github.com/lognaturel) pushes the releases to the Play Store following [these instructions](#creating-signed-releases-for-google-play-store). The code is "unfrozen" after a short grace period to make hot fixing easier.
+Releases are planned to happen every 2-3 months (resulting in ~4 releases a year). Soon before (or just after) the end of one release cycle, the core team will plan a new set of work for the next release based on the [ODK Roadmap](https://getodk.org/roadmap), bugs and crashes identified in and previous releases and other required or preemptive maintenance. This work will be broken down into Github Issues (for things that aren't already) by [@seadowg](https://github.com/seadowg) and is then is added into Collect's prioritised [backlog](https://github.com/orgs/getodk/projects/9/views/8) for the core team (and any external contributors) to work on day to day. Sometimes issues will be assigned to core team members before they are actually started (moved to "in progress") to make it clear who's going to be working on what.
+
+Once the majority of high risk or visible work is done for a release, a new beta will then be released to the Play Store by [@lognaturel](https://github.com/lognaturel) and that will be used for regression testing by [@getodk/testers](https://github.com/orgs/getodk/teams/testers). If any problems are found, the release is blocked until we can merge fixes. Regression testing should continue on the original beta build (rather than a new one with fixes) unless problems block the rest of testing. Once the process is complete, [@lognaturel](https://github.com/lognaturel) pushes the releases to the Play Store following [these instructions](#creating-signed-releases-for-google-play-store).
+
+Fixes to a previous release should be merged to a "release" branch (`v2023.2.x` for example) so as to leave `master` available for the current releases work. If hotfix changes are needed in the current release as well then these can be merged in as a PR after hotfix releases (generally easiest as a single PR for the whole hotfix release). This approach can also be used if work for the next release starts before the current one is out - the next release continues on `master` while the release is on a release branch.
 
 At the beginning of each release cycle, [@grzesiek2010](https://github.com/grzesiek2010) updates all dependencies that have compatible upgrades available and ensures that the build targets the latest SDK.
 

docs/CONTRIBUTING.md

@@ -29,7 +29,9 @@ To contribute code to ODK Collect, you will need to open a [pull request](https:
 
         git checkout -b NAME_OF_YOUR_BRANCH
 
-1. If there is an [issue](https://github.com/getodk/collect/issues) corresponding to what you will work on, leave a comment on issue asking to claim it. If there is no issue yet, create one to provide background on the problem you are solving.
+1. If there is an [issue](https://github.com/getodk/collect/issues) corresponding to what you will work on, leave a comment on issue asking to claim it. If there is no issue yet, create one to provide background on the problem you are solving. Issues that have been prioritised by the core team can be found in Collect's [backlog](https://github.com/orgs/getodk/projects/9/views/8).
+
+1. If you are an external contributor, make sure to discuss working on the issue with a maintainer who will then assign you to it. If you're on the core team you can either assign yourself to an issue in [the backlog](https://github.com/orgs/getodk/projects/9/views/8) and move it to "in progress" or discuss adding an item to the backlog with the reset of the team.
 
 1. Once you've made incremental progress towards you goal, commit your changes with a meaningful commit message. Use [keywords for closing issues](https://help.github.com/articles/closing-issues-via-commit-messages/) to refer to issues and have them automatically close when your changes are merged.