Project issues

[palfrey]

This is to some extent a continuation of #479, but also some other items. I'm interested in particular in @luciusmagn and @kud1ing's thoughts, but others are also welcomed

So, I'm feeling a bit burnout on this project, and as such will be switching off notifications on new PRs and won't be reviewing them for at least a bit. A lot of my issues come down to the following problems:

• Quality of repos: we don't really have any. It's called "Awesome Rust", and TBH our quality control (for which I'm as guilty as any) is not great. This results in a really long list, which is nice in certain ways, but I'm wondering if quality rather than quantity would be a better idea. I'm leaning towards more mechanical options of quality (e.g. Github stars or crates.io downloads), mainly to try and a) provide a consistent process and b) avoid the maintainers here being the judges of such matter, and using existing community metrics instead. If we do that, the thresholds should be clearly and publicly documented. There will always be popular projects that don't fit into any of the metrics, and in those cases we first need to find a new metric.
• Quality of list items: Our formatting is a bit of a mess. There's kinda a style, but it's not enforced, and there's kinda alphabetical ordering, but also not enforced. I think we need to have a fixed style, and enforce it. Main goal here is to reduce maintainer time i.e. make it easy to do the right route, so this should be an automatic thing. Probably a CI check. Maybe fits in with the JSON data concepts that were being floated in Awesome-rust Renaissance (Rework of the list) #479.
• Time spent on PRs: We need something like the Github pull request templates plus saved replies. The template should have a bunch of common issues to tick off, and there should be an expectation that if you open a PR and you've ignored one or more of those, it's getting closed pretty damn quick. It's somewhat of a jerk move, but from a "maintainer time" perspective, it's a win, and I think needed.

Thoughts anyone?

[kud1ing]

Hi,

So, I'm feeling a bit burnout on this project

I am sorry to hear that. But I can relate to this very much.

Regarding:

• Quality of projects to link to: i am all for quality over quantity. This is a quite subjective and difficult topic. Especially when it comes to inactive but important projects. Not sure whether an objective measure like stars really can reflect this.
• Quality control: i've always felt that a cleanup script is necessary to enforce a common style (to fix ordering, whitespace, dashes etc.).

Thanks for your work so far.

To be honest, i don't plan to invest much time in this project anymore. Maybe it's time to look for maintainers again or leave awesome-rust at it is?

[quintrino]

I'm also in favour of mechanical options of quality, if it's awesome it will reach a stage of popularity, and remove all elements of 'Is this awesome?' from the maintainers judgement feels more accessible and efficient as long as the metrics are clearly communicated.

Closing PRs quickly when they aren't completing the required steps seems fine, you can easily include a "if you get a chance to address these you're welcome to submit a new PR"

I think as long as you're clear on how everything runs you should definitely optimize for reducing maintainer effort.

Thanks for contributing to such a great resource!

[palfrey]

* Quality of projects to link to: i am all for quality over quantity. This is a quite subjective and difficult topic. Especially when it comes to inactive but important projects. Not sure whether an objective measure like stars really can reflect this.

My thinking on stars is that they're inaccurate at the high end, but useful at the low end. To give an example: if Project A has 1000 stars and Project B has 2000 stars, all we can really say is that both projects are popular and Project B has more people that have starred it, but would be hard to say definitively which one is more popular. OTOH, vs. Project C with 2 stars, we can say that both A and B are more popular. I think if we said something like 50 stars, or 1000 downloads on crates.io as a initial value and dug through and found the list of our current projects that would be removed and see if there's anything obviously great that wouldn't get there, and then look at those thresholds and see if we either need to tweak them or find extra ones.

* Quality control: i've always felt that a cleanup script is necessary to enforce a common style (to fix ordering, whitespace, dashes etc.).

To be able to do both of these easily mechanically, I'm currently leaning towards the JSON data file plus generation code to make the actual README.

To be honest, i don't plan to invest much time in this project anymore. Maybe it's time to look for maintainers again or leave awesome-rust at it is?

I think we could really badly do with more maintainers if you've got any ways of finding them. The project still has potential, but it needs this sort of level of overhaul to get it to a better place. It would be kinda ok as-is, but I think it could be better. I need some time away for a while, but I think if there's other maintainers around I could come back at some point.

[kud1ing]

I'm currently leaning towards the JSON data file plus generation code to make the actual README.

I've experimented with this in the beginning. This has a lot of advantages. The biggest two downsides are:

• it's less straightforward/harder/more unpleasant for people to contribute. I also fear confusion, that people will submit PRs to the generated README.md.
• there needs to be a generation step running somewhere at the right time. With GitHub actions this might be easier nowadays, i don't know.

[palfrey]

Updating on this one, as I came back and fixed some things:

• Quality is now mostly solved (for some values of) with Popularity filtering #1141 that implemented popularity filtering
• List ordering is fixed with Sort the README and enforce it with the checker #1121. Format is still a bit of a mess though.
• Time spent on PRs is way down. Mostly I just go "does it pass the CI" as that checks things like star counts, and "is it a ok formatted entry in a reasonable location" and then merge.