I should clarify that this wasn't intended to promote the RFC in general, but rather to ask for participation in the form of implementing a prototype of a particular idea that came up in one discussion (not a prototype of the RFC in general).
We have some more issues available for
async-std this week:
I'm seeking pre-release feedback for time v0.2! Having it in TWIR would be great.
"what" has some open issues that could be fun to hack on:
- This is an "easy" level low hanging fruit: https://github.com/imsnif/what/issues/17
- This is a larger feature that touches most parts of the application: https://github.com/imsnif/what/issues/16
I'd be happy to provide guidance on these or other issues.
"heed" really wants to compile and work on Windows, but I am not able to run the tests.
Would be happy to see some Windows user help us, It seems to be a simple path issue and doesn't require high skill.
Update: These have both been completed. Thanks!
We have a couple of feature requests in
smallvec that could be implemented as one-line functions (plus some simple tests):
I'm looking for some help in reviewing/improving documentation for four small, related crates, as well as writing tests exercising the API.
We got a nice issue for simd-json.rs today and I wanted to share it. It is not super hard but has challenging parts (a mini parser) and can be fun to do since results will be directly usable and tackles a few different angles (perf, usability, api design). If someone finds this interesting but isn't sure they are up to it I'll gladly spend some time mentoring.
I have an issue that somebody can work on:
We have some issues in
bandwhich that could use some work, some of them bite sized and good for beginners:
Help me port hyper and body-image-futio to async-std so we can run comparative benchmarks, as reported here for tokio:
Implementing a simple derive in SQLx with mentoring instructions from a proc-macro guru (me):
Working on a Rust implementation of Celery with the goal of being fully compatible with the Python version so that tasks can be sent from Py -> Rust or vice versa.
Any issue marked "Status: Help Wanted" would be a good place to start for newcomers.
Implement function returning the local UTC offset for the time crate
I don't have the necessary knowledge or experience to be able to do this, let alone appropriately. A PR will happily be accepted. I can do the documentation and tests.
Someone needs to merge the
remove_dir_allcode into the standard library. This is a crate that created as a quick workaround for crates from an implementation from #31944 that never got merged. It's been pretty stable over the past few years, and is used in cargo and rustup.
Since creating the crate, I no longer have a Windows machine. As a result I do not intend to maintain the crate. It would be great if someone could port the code into std so that everyone can have a reliable implementation on windows.
If I had a Windows machine, I may try that issue.
I'm making a WebAssembly demo for the
arcs crate and was wondering if someone could give me a hand.
I'm more than happy to help mentor.
Diesel is looking for persons willing to do some code review on submitted PR's. You don't need to be familiar with Diesel's internals to help. We are happy to answer any question about any code fragment that comes up in a review, so that's a great way to improve your understanding rust's trait system and how to build complex systems on top of that.
I got some good info & code last time around, but I still need someone (or many people!) to do a code review of the gist linked in the comments here. Mostly centering around correctness (which I'm pretty confident on) and safety (syscalls).
image crate reworked its error types in the latest release. The new types can provide much more information such as underlying error sources, ties to the format, etc. however the existing decoders and encoders do not currently fill in that information. We're looking for contributions to migrate these to the new representation in this tracking issue.