[DO NOT CLOSE] TorchRL call for contributions and near-term focus

[vmoens]

TorchRL call for contributions

Last reviewed: August 2026

This is a living contributor hub for TorchRL's current priorities. It is not a release schedule, and the focus areas may evolve as designs land and project needs change.

How to contribute

1. Pick an open issue below and read its latest discussion.
2. Check the assignees and recent comments before starting.
3. Comment on the issue to agree on scope, especially for RFCs and assigned work.
4. Follow the repository's contribution guide for implementation, tests, documentation, and pull requests.

If you would like to propose work that is not listed here, open a dedicated issue first. New entries in this hub must point to an open issue with a clear motivation and enough scope for contributors to discuss or implement.

Near-term focus

Post-training interoperability

Make TorchRL's post-training components easier to adopt from existing ecosystems and training loops.

• [RFC] Post-training efforts #3948 — overall post-training interoperability direction
• [Feature] WS2: TRL Interoperability Adapters #4058 — TRL interoperability adapters

Scalable asynchronous collection and inference

Improve throughput and ergonomics for large asynchronous environment fleets and accelerator-backed policies.

• [Feature Request] AsyncEnvPool v2 #4061 — AsyncEnvPool v2 and its shared-memory, batching, and inference path

Replay-buffer composition and update safety

Separate sampling concerns cleanly and make delayed mutable updates safe under storage reuse.

• [Feature Request] Separate replay selection distributions from sampling units and boundary policies #4039 — compose selection distributions, sampling units, and boundary policies
• [Feature Request] Add generation-safe conditional updates for mutable replay fields #4040 — generation-safe conditional updates
• [Feature Request] Add generation-stamped replay indices for safe delayed priority updates #4041 — generation-stamped replay indices

Monitoring and consistent runtime APIs

Improve observability and make configuration consistent across collectors, evaluators, replay buffers, and inference services.

• [RFC] Add a general monitoring and logger attachment API for collectors and replay buffers #4012 — monitoring and logger attachment APIs
• [RFC] Unify device configuration across collectors, evaluators, and the inference server #3943 — unified device configuration

Ways to contribute now

Implementation opportunity

• [Feature Request] Implement TQC for the example algorithms #1623 — TQC example algorithm. Review the current ownership and discussion, then coordinate scope before opening a PR.

Design and discussion opportunities

These RFCs are open for concrete API feedback, use cases, and implementation trade-offs:

• [RFC] Add a general monitoring and logger attachment API for collectors and replay buffers #4012 — collector and replay-buffer monitoring
• [RFC] Unify device configuration across collectors, evaluators, and the inference server #3943 — device-placement configuration

Coordinate before coding

The post-training, AsyncEnvPool, and replay-buffer workstreams above are active, larger efforts with current ownership. Focused prototypes, benchmarks, tests, documentation, and scoped implementation help may be useful, but please agree on the boundary in the linked issue first.

Keeping this page current

• Every listed item must have a dedicated open issue.
• Completed or deprioritized items should be removed instead of kept as a historical archive.
• Closed issues and release notes are the source of truth for completed work.

Thanks for contributing to TorchRL!

[gtnv]

hi @vmoens this seems a little outdated can you have claude writeup a new roadmap at least for the immediate future? thx

[vmoens]

Fair point — thanks for the nudge. I have refreshed this into a current contributor hub, removed the stale and completed backlog, and added the near-term focus areas backed by active RFCs and issues.

I am keeping it distinct from a release roadmap: these are the areas where design and implementation work is active, without implying delivery dates or commitments.