Hi there. Please allow me to tell you about another cool thing Rust needs, and needs help with.
There is an endless stream of newcomers to the project looking for ways to help. We are pretty good at giving them direction, but we can always improve. And with the community team, Mozilla, and others planning increasingly more Rust onboarding events we need more sophisticated ways of funneling users to easy/important tasks.
Servo has a site called Servo Starters that aggregates contribution opportunities across their repos, and people seem to like it. Let’s have the same for Rust, by adapting the source and deploying it to a tiny cloud instance somewhere.
Here are a set of links that should be reflected in a Rust Starters site:
For now I’d suggest we limit it to official projects (with the exception of clippy, which is all-but-official and maintains excellent newbie bugs). It’s really important that the bugs here are well curated and actionable.
If someone were to set this up we could direct starters.rust-lang.org to it.
Anybody have opinions on this subject? Anybody want to make it happen?
I started to work on something like this a week or two ago (after seeing a post of yours). I started from scratch and in Rust with the following goals:
Nice minimal design
Once deployed, minimal maintenance
Users should be able to add repositories to the watchlist easily
Use a special label name (like rust-starters) that can be used across the community
Limit spam repos by checking for issues with the label before adding to the watchlist
Possible support for alternative git hosting services (e.g. GitLab)
So what I had in mind is creating a webapp with iron and have a db managed with diesel. The db would have 2 tables, one containing repos to watch and the other would contain the issues associated with a repo from the first table.
On the front-end we would allow various ways of sorting and browsing the issues as well as add new repositories to the watchlist. This would be as easy as entering the hosting platform (e.g. Github) followed by the repository namespace. To avoid spam, the repo would only be added to the watchlist if there is actually and issue tagged with the pre-defined label.
I think the advantage of having a db instead of static site is that new repositories can be added by the community without needing the intervention of a maintainer through a PR or something, reducing the maintenance cost.
As for the actual implementation, I have not yet pushed anything online because I have run into some trouble with serde and diesel not agreeing on the nightly version to use (see this issue).
I would rather just use the servo-starters code and share it.
It needs some improvements for this to work. Right now it scrapes all repos under the servo org and searches for issues tagged E-easy or easy or E-less-easy. It can’t be configured for individual repos, only entire orgs. We’d need to tweak it so that it can be given both individual repos and orgs. But besides that, it works well and should be easy to use.
The reason I decided to start from scratch is that everything is a little too hard-coded in the servo-starters code, and I liked the idea of everybody being able to add their repos if they mentor issues.
I’d love to be able to sort the issues by the required level of Rust knowledge (and also to have some more advanced issues on the list).
It seems to me that there are a number of developers who already know a fairly big chunk of Rust but don’t have a project of their own to work on. It would be nice to guide these kind of rustaceans as well.
I think a one-time pull request to add a repo is a low enough barrier. Also, it lets us audit them before they are added – this site is (or will be) the face of contributing to rust for newbies, so we want to ensure that projects are actually mentoring.
@Azerupi Oh my, that sounds cool. How far along is your project? I hate to discourage you if you have momentum, though it does seem advantageous in some ways for Rust and Servo to share a codebase. The most important thing is something gets done, and the second most is that somebody maintains it.
@matklad I agree. We see threads all the time saying 'what should i work on?'. There are so many potential green-field projects of strategic importance to Rust. Right now there's no clear way to communicate them. Sometimes I will post a call-to-arms (like this one!) on the forums, but sometimes I don't because I feel bad about the noise, or don't want to put the initial energy into writing it up.
I do worry about making things like this completely open and expansive - if everybody throws in their ideas it could create a lot of noise, make it hard to know what's important.
Not that far
I am waiting for Diesel and Serde to play nice together. Diesel only supports the nightly from the dates of the Rust releases and Serde had loose dependency constraints on a crate using compiler APIs, causing old versions of Serde to not compile anymore, even though they did when they were released. But the Serde devs have promptly fixed the issue for future releases when I reported it. So now I'm just waiting for Diesel to bump the nightly they support and then I should be able to use both without any hacks.
Anyways, my motivation comes from the fact that I maintain a project where I would gladly mentor some issues, but those issues do not have enough exposure to beginners to be helpful. I know TWIR maintains a list of simple mentored issues, but I don't feel like it's the right place to post issues from my personal projects.
So my take on this "rust-starters" project was more oriented towards project authors of the community who would gladly mentor issues on their project but have not enough exposure to do so.
I will probably continue to tinker with this project and, who knows, maybe it will turn out to be useful
I have an old-ish fork of servo starters live and pointed at Rust at http://edunham.github.io/rust-starters/. We could move it to the nursery and keep it up to date, but when I first set it up the Rust trackers weren’t doing so well on flagging easy issues.
The Github issues search API accepts a user/org or repo. Like servo-starters, it searches all rust-lang and rust-lang-nursery repos, which results in fewer requests but might include issues from deprecated repos
It looks like rust-lang doesn’t use C-assigned or C-has open pr labels (unlike servo), so those aren’t used in the API calls
The language filters on servo starters could be used for different application domains (lang, tools, docs, graphics, etc.) or project name filters (rustup, cargo, etc.) or we could pull cargo metadata, but I wasn’t sure which way to go there.
If rendering the issue lists gets too slow as we add repos, it could be changed to render as soon as each XHR comes back instead of waiting for them all to finish.
I reached out to A.L. Palmer for permission to use the animated rustacean and find out how hard it’d be to switch to a transparent or white background, but it can go away if it’s too distracting. It was useful for telling rust and servo starters apart. (Edit: got the OK and switched to a higher res white background Ferris she provided)
Nice to haves:
support projects at more hosting providers like: bitbucket, gitlab (as @Azerupi mentioned)
integrate with “this week in {rust, rust-docs}” emails and other sites like openhatch.org
I am waiting for Diesel and Serde to play nice together. Diesel only supports the nightly from the dates of the Rust releases and Serde had loose dependency constraints on a crate using compiler APIs, causing old versions of Serde to not compile anymore, even though they did when they were released. But the Serde devs have promptly fixed the issue for future releases when I reported it. So now I'm just waiting for Diesel to bump the nightly they support and then I should be able to use both without any hacks.