Some of these items can be achieved by combining existing tools, but others may require us to build bespoke software solutions. See [build-vs-assemble] to understand trade-offs between these approaches. If a feature can be implemented by contributing to [recipes], it should.
Items that are already being worked on. Roadmap items in this stage should have an owner.
Items we plan on working next. Items in this stage don’t need to have an owner, but before we start working on them should have enough specification that they can be picked up and worked on without having to seek consensus.
If you want to pick up work in this category, you should have a plan on how long the implementation will approximately take so we don’t block progress by sitting on high priority issues.
Everything else, categorised into themes. Just because something is on this list doesn’t mean it’ll get done. If you’re interested in working on items in this category, check the [contribution-guide] for how to get started.
If a roadmap item is a stub, consider opening a GitHub issue to start a conversation to avoid situations where the implementation does not fit long term vision and roadmap. Note that this is optional. The only centralised governance in Foam is to decide what ends up in the official template, documentation and extension. You are free to build whatever you want for yourself, and we’d love if you shared it with us, but you are by no means obligated to do so!
When creating GitHub issues to discuss roadmap items, link them here.
The community is working on a number of automated scripts to help you migrate to Foam. The main work of developing such a method involves exporting your notes, converting them to the Markdown format, and then making sure that the links between notes (if you had those) still work.