Expand Libs docs with more links and details

[KodrAus]

Currently includes two new sections:

• An RFC Merge Procedure that just points to the Lang one, just so it’s easy to discover for anybody who needs to merge Libs RFCs.
• Some external links in the form of a table in the root Libs page. These are just some GitHub queries that I find regularly useful.

cc @rust-lang/libs what do you think of the idea of using a GitHub topic on repositories in rust-lang to surface repositories we want to keep track of? As a start I’ve just added it to log but thought we could also include:

• libc
• futures-rs
• backtrace-rs
• api-guidelines
• packed_simd
• stdarch
• regex
• hashbrown
• getopts

What do you think?

[XAMPPRocky]

@KodrAus Not on the team, but I would love if there was a list somewhere even if it wasn’t a GitHub Topic that said which of the repositories in rust-lang the libs team takes responsibility for. It would be very helpful when figuring out who needs to be contacted about the crate for whatever reason.

[KodrAus]

I would love if there was a list somewhere even if it wasn’t a GitHub Topic that said which of the repositories in rust-lang the libs team takes responsibility for

I think this would be great too 👍 I thought a GitHub topic might be a nice way to keep the set relevant so we don’t have to maintain a manual list.

[LukasKalbertodt]

Thanks for your work! The forge for t-libs could indeed be improved!

cc @rust-lang/libs what do you think of the idea of using a GitHub topic on repositories in rust-lang to surface repositories we want to keep track of?

I don't mind that, but in case you aren't aware, there is also this: https://github.com/orgs/rust-lang/teams/libs/repositories
Not sure how useful that is though. It seems to be all repos that the team has some kind of explicit access to?

And regarding responsibility of repos in rust-lang: it miiight be helpful to assign people from our team to certain repos as "mainly responsible"? To be honest, I unsubscribed from a few repos as all PRs were way over my head and someone else already seems to handle everything. But yeah, maybe it's not a good idea after all, and everyone from t-libs should check every repo once in a while...

[KodrAus]

I unsubscribed from a few repos as all PRs were way over my head and someone else already seems to handle everything

@LukasKalbertodt That’s not a problem at all! 🙂 There are so many repos that libs works on and the highest traffic of them are very domain-specific so unless you’re immersed in them it’s very hard to keep track of individual issues and commits.

it miiight be helpful to assign people from our team to certain repos as "mainly responsible"?

Having a list of repos along with a libs contact might help to unblock things that come up in those repos, especially for folks outside the team who can’t ping the team have a handle they can ping instead.

[XAMPPRocky]

Having a list of repos along with a libs contact might help to unblock things that come up in those repos, especially for folks outside the team who can’t ping the team have a handle they can ping instead.

I think this would be a great use for project groups. A project group can be scoped to a single crate e.g. a backtrace-rs project group, that would consist of primarily one or two people working on the crate. This would allow the groups to benefit from all the team infrastructure like being on the website and having automatically having a github team like @rust-lang/libs/backtrace-rs. This would be more effort than just a list though.

[KodrAus]

Another alternative could be to use a GitHub issues like the Lang team does for their project groups: https://github.com/rust-lang/lang-team/labels/project-group

[KodrAus]

I’ve just removed the link to a list of repos in topics for now so we can still include some useful links in the forge docs and decide how we want to track repos later on.