The whole crate needs some love, but the addition of integration testing is arguably the most important, to ensure correctness. Current contributors, including myself, unfortunately don’t have a lot of free time to dedicate to the crate. There are several issues that are tagged as help-wanted.
For those interested in experimenting with tokio, there’s also this issue:
Hi! I’m helping out with crates.io now, and I’d love to help get more people contributing. I’ve got 6 E-mentor tagged issues right now that I’ve added some description to as to what’s needed to fix them. I’m going to try to keep it around that number and be responsive to questions. I’d love if some of these ended up in TWiR regularly!
I’m looking for somebody with a little experience in gnome or kde development to add a missing feature to notify-rust, a desktop notification library. The spec (on gnome at least) supports inline images in notifications though paths or by sending bitmap data directory.
I consider this medium since it requires doing a bit of research by may ultimately not involve too many lines of code 
. Anybody interested in improving the rust desktop integration story? 
I’m looking forward to your PR resolving this issue.
I’m looking for somebody to fix a long-standing bug in the tempdir crate, and publish an improved remove_dir_all function to crates.io in the process.
The issue is that the std remove_dir_all doesn’t work correctly on windows:
https://github.com/rust-lang/rust/issues/29497
This hasn’t been fixed in-tree, where PRs get a lot of scrutiny, but it affects real code, and I open code a bad remove_dir_all myself anytime I need to remove_dir_all. In the meantime, tempdir, a popular crate with a desperate need to remove dirs, is affected by this bug.
There’s a PR open to fix tempdir:
https://github.com/rust-lang-nursery/tempdir/pull/17#issuecomment-285835625
But it is stalled. Here are my comments about what needs to happen next:
https://github.com/rust-lang-nursery/tempdir/issues/15#issuecomment-286513675
That last issue is probably the one to link from twir.
The Ion shell project that I maintain could use some contributors to implement missing features, either in Ion or the accompanying liner project. If anyone asks, I can easily provide mentorship. I’ve done a lot of work to rewrite and complete as much of the shell’s missing features as I can, but there is still much work to be done in order to compete against existing shell languages. The codebase should be much easier to read/manage now.
Let us know links to the issues that we should post.
Rusoto, the Rust AWS SDK, is looking for maintainers. If you’re looking to learn more about Amazon Web Services, code generation in Rust or want to check out one of the bigger public code bases around (claim not validated in any manner), come check out the repository. The CONTRIBUTING file has instructions for getting started.
If documentation is more your bag, we’ve got https://rusoto.org/ which is a gitbook companion for the project. The source is on GitHub as a project under the Rusoto org on GitHub.
I’m available for mentoring.
Basically, if there is an issue that does not have an assignee, we are seeking help for implementing that feature.
I’d suggest creating a new issue looking for maintainers with information on how to contact and we’ll link to that.
https://github.com/rust-lang-nursery/lazy-static.rs/issues/67
https://github.com/rust-lang-nursery/lazy-static.rs/issues/68
https://github.com/rust-lang-nursery/lazy-static.rs/issues/69
Hi. I’m looking for people interested in crypto, command line and backups. Rdedup started as a little project for backup deduplication, but PR after PR, it’s growing into very efficient and robust multipurpose deduplication machine. Check the github repo: https://github.com/dpc/rdedup , read github issues, read an article on how high performance through parallelization is achieved: http://dpc.pw/blog/2017/04/rusts-fearless-concurrency-in-rdedup/ and feel free to ask questions on gitter channel!
Hi,
We are looking for people to join our mission of building an event sourcing database engine. Event sourcing is a pattern in which, instead of storing the current state of the data and using it as a source of truth, one should immutably record the full series of actions taken and designate that log as a source of truth instead. This approach can simplify tasks in complex, changing domains by avoiding the need to synchronize data models and domain models. It also provides great auditing and transactional capabilities, as well as opportunities for lossless error correction.
The core ideas behind our project (PumpkinDB) stem from the so called lazy event sourcing approach which is based on storing and indexing events while delaying domain binding for as long as possible. The intention of this database is to be a building block for different kinds of event sourcing systems, ranging from the classic one (using it as an event store) all the way to the lazy one (using indices) and anywhere in between. It’s also possible to implement different approaches within a single database for different parts of the domain.
We’ve been previously nominated as a Crate of the Week and have grown our followers base significantly since the first announcement.
We are gearing up for the next release and have recently pushed out some exciting bits (like SPDK bindings for Rust for our future direct NVMe storage module). We are working on examples and articles to explain our ideas in more details to make the project more accessible in the short term.
As per our contributions guidelines:
We also maintain a list of “starter issues” and will be happy to chat in our Gitter room!