Here is my (@mxinden) proposal for a roadmap for the next 6 months for the rust-libp2p
maintainers (@elenaf9, @thomaseizinger, @jxs and @mxinden) working on the rust-libp2p project.

(rust-)libp2p is an open source and open community project. Thus:

- I want to make sure we listen to the community and align our work accordingly. I invite
  **everyone** to leave feedback here.
- The below is only planning work for the maintainers, not the community. Folks from the community
  may suggest and pick up work not prioritized (e.g. [Kademlia efficient
  querying](#kademlia-efficient-querying)) nor mentioned on this roadmap and we (maintainers) should
  be supporting them as best as we can.

I consider this more of a short-lived document, enabling everyone working and using rust-libp2p to
discuss and eventually align on a common mission, making prioritization explicit. Once done, it will
likely be outdated quickly and thus I suggest never actualy merge it. In my eyes, continued
project management is better done via GitHub issues and thus all the information here should
eventually make it into the corresponding GitHub issues if not already the case.

Also see:
- [libp2p roadmap](https://github.com/libp2p/specs/blob/master/ROADMAP.md)
- [go-libp2p roadmap](libp2p/go-libp2p#1784)

The items in this roadmap are ordered by importance where I define importance as:

- Enable others to build with rust-libp2p before building components ourself.
  - e.g.[cross behaviour communication](#cross-behaviour-communication) over[Kademlia client
    mode](#kademlia-client-mode) where the former enables the latter
- Invest into tools that enable us to work more efficiently
  - e.g.[Testground](#testground-abstraction) and [release process](#release-process)
- Better do one thing well than many things close to right.
  - e.g. deprioritize [BitSwap implementation](#bitswap-implementation) and continue on
    [QUIC](#quic-support) even once first ieration is merged. That does not imply that we won't
    support community members implementing it.
- Improve existing components before introducing new ones.
  - e.g.[Kademlia client mode](#kademlia-client-mode) before [WebTransport](#webtransport)

I am curious what folks think and again encourage everyone to share their thoughts.

This is tracked on the [libp2p test-plans](libp2p/test-plans#44) see also
libp2p/test-plans#53.

This is not interesting in itself for stakeholders. Instead it will be tracked with the cross
behaviour communication. See also libp2p#2832.

This is not directly relevant for stakeholders. Will be tracked on the project board.

https://github.com/orgs/libp2p/projects/4