add test tools team #1054
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,22 @@ | ||
| name = "test-tools" | ||
| subteam-of = "devtools" | ||
|
|
||
| [people] | ||
| leads = ["calebcartwright"] | ||
| members = [ | ||
| "calebcartwright", | ||
| "epage", | ||
| "Muscraft", | ||
| "thomcc", | ||
| "weihanglo", | ||
| ] | ||
|
|
||
| [[github]] | ||
| orgs = ["rust-lang"] | ||
|
|
||
| [website] | ||
| name = "Test tools team" | ||
| description = "Defining strategy and associated tooling for supporting automated testing activities in the development workflow" | ||
|
Contributor
There was a problem hiding this comment. This also focuses only on the tooling and not on the library side of things From the RFC, we put our mission down as
Member
Author
There was a problem hiding this comment. To make sure I fully understand, are you saying you'd rather reuse that sentence from the RFC verbatim, or just that you feel this isn't a complete description and needs to be changed? FWIW I don't think the one liner blurbs from the website trump the official scope articulated in places like the RFC and associated team repos. I've always looked at the governance pages of the website as extending to a much broader audience, including those who've potentially never seen (much less written) a line of Rust code, and I think it's helpful to try to generalize things as much as possible in that context. I personally view "tooling" as such a generalized word that would extend to frameworks, runners, libraries, etc. and not be exclusively scoped to command line executables/subcommands. However, I'm fully open to any alternative phrasing though if there's any suggestions
Contributor
There was a problem hiding this comment. I was using that line as a point of comparison or idea generation. For me, tooling is programs / automation and not the whole experience and I suspect a lot of people would be thrown off by the intent of the group if the name and/or description emphasizes tooling.
Member
Author
There was a problem hiding this comment. That's fair. I'd like to avoid mentioning I'll think on this some more and try to come up with some proposals, and would encourage others to share any ideas as well
Contributor
There was a problem hiding this comment. As @thomcc says, this can always be changed later so it just has to be "good enough" |
||
|
|
||
| [[zulip-groups]] | ||
| name = "T-test-tools" | ||
calebcartwright marked this conversation as resolved.
Show resolved
Hide resolved
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My only nit with the name is it makes it sound like we are focusing on
cargo test,cargo bench, etc and not on libtest.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Naming things is hard. Would you prefer sticking with T-testing? Or is there an alternative name you'd suggest?
What would you think about something like... Testing experience team?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To add to naming being hard is I saw some confusion over people thinking we were focusing on testing of rustc...
While not ideal, I'm fine with "test" and "testing". I'm also fine with emphasizing the user experience in the name
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
T-testing feels like it captures the scope better, but I don't really care. I also don't know if I think that the possible confusion is a huge problem.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For myself, I'm still not sold on "tools". I understand that for some, it more is being used like "resources" but naming matters and can help shape thought and behavior, both of the team and those who approach it. We'd be working against the psychological aspects of that by biasing the name (this is especially true when the membership is also biased towards "tools").