Does anyone know where the libs team hosts their discussions? I couldn't find a
t-libs channel on Discord. There is discussions here for stdarch and the allocators WG, but I couldn't find a general channel ala #t-lang.
@XAMPPRocky they are on irc/matrix
I would need more information than that to actually find them.
#rust-libs on mozilla's servers
They don't use IRC anymore AFAICT.
Most of them are here on zulip, but essentially they just use issues tagged with T-libs, @rust-lang/libs, etc. to communicate. There are also no meetings.
All of them read internals.rust-lang.org, so you can open a new libs thread there as well.
@gnzlbg I find this a bit concerning to be honest. Every other team has a dedicated discussion forum, both for people to come ask the teams questions and for members to discuss topics, having no meetings seems especially odd given that there's over 600 open issues and PRs tagged with the libs team and there seems to be no form of triage, even the community team has monthly meetings. Both these aspects makes the libs team appear overly closed off compared to every other team in terms of participation.
@XAMPPRocky The libs team is more bandwidth-limited than most others currently -- a sync communication channel requires non-zero amounts of effort to maintain; if you need something specific then I can reach out if it helps and try and connect you with someone.
@simulacrum I don't mean a sync channel, I mean an async channel like a stream in zulip or a channel in discord. I would accept being bandwidth limited more if there was a clear way for people who are not in the libs team to help with that bandwidth constraint, however that is not the case so bandwidth being limited is a self fulfilling prophecy, people don't know how to participate and help, so no one does, so there's only a few individuals who can.
It is a known problem and one that is on core team's mind for something we want to solve. I agree with you that the current situation is not ideal.
(it is my impression that an async channel -- e.g. Discord/Zulip -- is at this point unlikely to be super helpful, either)
I don't think a channel would be the sole solution to this problem. The solution is to get more people involved, and in order to organise that kind of effort you need to place to communicate.
I feel like you're not wrong, but we currently are not at the point where we're ready to get more people involved, etc.
Okay, but what do we need to do get to the point that people feel like we're ready to get more people involved? That answer is dissatisfying to me because it feels like a stonewall. Of course I know, and don't expect you personally to be able to answer this question, but there has to be some way to make actionable progress in this area.
I think time, primarily, and probably some internal discussions -- I agree it's a stonewall, it's "intended" to be so, I'm afraid. I'm not really sure I can offer more guidance and we're heavily bandwidth limited right now
@XAMPPRocky I don't think that's a problem, every team chooses its own communication channels and what works best for the team. The libs-team chooses to use github for everything, and I think that's quite approachable. The barrier of entry is definitely lower than requiring Zulip, Discord, or IRC.
Also it is not true that there is no progress in the issues tagged with libs-team, I regularly see FCPs being opened, discussions happening, and progress being made. You can check the FCPbot website to know what's being worked on right now.
@gnzlbg GitHub is not a communication channel, unless there was a libs-team repo like how other teams and working groups use GitHub, we would not recommend people to ask their libs team questions by filing issues on
rust-lang/rust for example. I never said there was no progress on T-libs issues, I said there's no triage so what issues do make progress feels arbitrary (Of course this is not a problem that's unique to the libs team, but doesn't make it less of a problem.) Teams are free to organise however they want, however it's important that, that is done in an open fashion that allows for new contributors and team members. Through that lens the libs is probably the most closed team we have.
IIUC the way triage works is, if a team member thinks there should be progress in an issue, either they push the issue forward, of it it is ready, then FCP it.
we would not recommend people to ask their libs team questions by filing issues on rust-lang/rust for example.
That's pretty much how I understand this works.
If you want a specific example of how the current process has failed, you can look at rfc#1937 and the fact that
Debug and not
Display. There's been no real retrospective or change in the process as result of this and I'm not confident that this kind of mistake won't happen again.
I don't see that as a failure in the process, but rather as the process working as expected.
Termination requirement of
Debug went through the RFC process IIRC, and that was stabilized.
Only after stabilization people started a discussion of changing that to
Display, but that's a backward incompatible change.
Nobody has submitted an RFC that's backward compatible and fixes the issue.
The outcome of this is obviously not good, but the only thing that would have helped is if more people would have participated in the RFC review, or experimented with it on nightly and gave feedback _before_ stabilization.
The compiler and lang teams have the exact same problem (lack of users participating in the RFC process, or testing on nightly), with the same outcome (issues being discovered after stabilization).
For example, the RFC that you point to was mainly handled by the lang-team, which had a communication channel in Discord at the time. So its unclear to me how adding a similar communication channel for the libs team would prevent this particular issue.
@gnzlbg If you read the tracking issue (which is hard since most of it is long and hidden), the people that brought up the issue are libs team members not external members in the community. When you have no easy communication and no active triage, you'll always be reactive to issues not proactive which is the actual problem I'm talking about, not the outcome of this particular rfc.
@XAMPPRocky pinging the libs team on that issue would have been as easy as tagging the issue T-libs, or writing "@rust-lang/libs"
yet the teams that were assigned to and signed on that feature were the lang and dev teams
even if the libs team had a triage process, that process would only apply to issues for which the libs team is responsible
and that particular feature wasn't one of them
also, during that time, the libs team was using IRC for communication, so they had an active communication channel, and that did not help avoid this because the process failed somewhere else
In this particular case, the RFC was tagged T-libs and T-lang, but the tracking issue only T-lang and T-compiler, and the stabilization was signed off by T-lang and T-devs-tools.
@XAMPPRocky you are not the only facing this. I've faced it a bottleneck while triaging as well. Trying to find ways we can improve this situation in 2020
It's a "well known" gap in the process.
people who care to interact with T-libs almost immediately hit the problem
you are not the only facing this. I've faced it a bottleneck while triaging as well.
What issues have you run on? @rust-lang/libs works within the rust-lang org at least.
@gnzlbg only team members can ping teams though
FWIW, my personal experience is that I have to ping specific lib team members; pinging the entire team sometimes results in no reaction at all.
Ah, I thought everyone could just ping the libs team whenever an issue pops up.
If a ping to the team is the preferred way of interacting with the team, anyone should be able to ping them.
anyone should be able to ping them
good luck convincing github
put a bot on the team and ping the bot and it pings the team then.
or the team should get a better communication channel.
Not being able to ping teams on github if you are not on a team is a general problem.
@Lokathor You don't need a bot, you can just ping the entire team but then it happens in many teams that people see the team ping and think "somebody else will take care of it" so it just passes around :joy:
you can't if you're outside rust-lang
Yes I meant for someone from the organisation