Alright. @nasa42 @llogiq what's your stance on this? Should TWiR be used to "bump" RFC threads at all (in addition to those that are already mentioned due to being new, recently closed, or in FCP)? If the answer is yes, should the Call for Participation section / this thread be used for that, or something different?
I've created two more tasks in spirit (library to help cut down on boilerplate around configuration reloading and application). They are probably medium-sized tasks and might have few hidden traps I don't know about yet, but I'll be there to help solving them if they appear.
I am looking for contributors for this issue, to create vectorized math functions ala Agner Fog's C++ library in Rust:
RFCs already get visibility through "New RFCs" and "Final Comment Period" sections and I think adding them to also "Call for Participation" would be distracting from and unfair to other issues.
Hey there pal, I've got a great lib in progress on that front. Don't wanna clog the thread of course, my Twitter is @Lokathor or I'm on the community discord as well.
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.