# Development Governance There would be 2 primary places for discussing potential future development: - Feature Requests - RFCs ## Feature Requests Anyone can put in a feature request with as much or as little detail as they'd like on a respective repo (and can be transferred between repos as needed). A filtered view of issues tagged as "Feature Requests" can help with sifting through them and continuing conversation: [Feature Requests in the Tauri repo](https://github.com/tauri-apps/tauri/labels/type%3A%20feature%20request). A feature request can easily be turned into an RFC if required. Feature Requests are already an issue on a respective issue and thus that issue can be used to track the status. ## RFCs We have the RFC repo here: https://github.com/tauri-apps/rfcs/. This serves as a home for discussing potential significant changes to Tauri. RFCs have a natural, self-contained process for being proposed, discussed and accepted or denied (covered in the README PR mentioned below). After being merged in there is still the need to track it's progress and status if and when picked up. That's where a tracking issue or an implementation PR in a respective repo can be used. Jonas has put in an updated template for an RFC here: https://github.com/tauri-apps/rfcs/pull/7. I've put in a PR for updating the README there to cover the thoughts here: https://github.com/tauri-apps/rfcs/pull/8. ## Tracking & Status With the assumption that RFCs have tracking issues created and Feature Requests are issues themselves, the question of keeping track of the various states comes up. These can be across multiple repos and have dependencies between them. I'd like to propose adapting the [roadmap the YuWei has created](https://github.com/orgs/tauri-apps/projects/11/views/11) as a central mechanism to track the progress of these items. This can be used as a way for the development domain to promote items they'd like to put on the roadmap or keep an eye on. Right now there are 4 status defined on the roadmap project: - Backlog - In progress - In audit - Done I'd like to propose adapting the definitions to the following: - Backlog - Items that the team would like to include in Tauri on **but aren't yet slotted for a release** - This includes the RFC tracking issues or implementation PR, feature requests, and any additional ad-hoc items as needed (although ad-hoc items should be used with discretion) - This doesn't need to include every single issue that's to be developed, but instead those that the team would like to give more visibility to or wishes to track - Planned - Items that are tagged with a specific target release (using the custom field) and the team has agreed to take on but aren't yet under active development - In progress - Actively in development and may have a specific person/champion assigned to the issue - Done - It's merged in! (not necessarily released yet) ### Open Items - How do we handle auditing status with this?