spin off docs.rs team from rustdoc team #182
Conversation
|
To add some details: it's been some time that the Docs.rs team creation has been brought up, so I think it's finally time to give it an official status considering how important it is. |
|
cc @rust-lang/core I'm fine with this from the devtools side, but folks may have opinions |
|
I don't think it should be placed under dev-tools as well: it should either be standalone or under infra. |
|
I'm fine with it being standalone - then it would be following the example of the Crates.io Team. |
|
On our website, we have a notion of the "Operations team". I think this team would fit well into that umbrella. I suppose then that the "infra" team is really about "non end-user facing infra", for the most part, but for user-facing infra (e.g., crates.io, docs.rs) we use distinct teams? There are some questions that traditionally arise for new teams. Most notably, does this team require core team representation? Procedurally, I feel mildly uncomfortable creating a new top-level team in a PR to this repository. I feel like we have traditionally created teams using RFCs, and I am reluctant to move away from that precedent. (It occurs to me I may be wrong, but I guess I think we should be using RFCs more in general, so if we didn't, I think that was a mistake). I don't think an RFC on this topic would be especially controversial, of course -- though it would introduce a mild delay to permit the FCP period to expire. (I suppose that a fcpbot merge for T-core might suffice.) |
|
(By the way, in case it's not clear, I am super excited for this team to be created!) |
TBH I don't like the "Operations team" umbrella on the website, as infra and release's responsibilities diverged since the creation of the release team. What I would is to split off release and infra on the website, and put docs.rs under infra. |
|
I'm a bit uncomfortable with it being under infra mostly due to the end-user-facing/non-end-user-facing distinction made by Niko. There's infra work involved in keeping it running, but it's also a website with end user facing features and UI work, much like www.rust-lang.org and crates.io. Infra is a horizontal, if something fell under infra because infra work was involved then most things would be under the infra team 😄. I do think it's a bit important to get the home right because that's how priorities get set for a project. (It's worth looking at this more holistically along with crates.io and www.rlo as well. The website is kinda awkwardly under community right now, and crates.io is toplevel) |
|
Hmm, it seems like the new-team proposal is surfacing some related concerns that should probably be resolved before this can be merged. Let me see if i can summarize:
The last bullet points get at what i think the decision should be (i.e. the RFC that i would write today without other input). Comments made by @nikomatsakis (#182 (comment)) and @Manishearth (#182 (comment)) suggest a potential new "umbrella" team for their notion of "end-user-facing infra". The Release Team is the closest currently-existing analogue i can see that would serve as an umbrella organization, since they already manage the release process, which means that @Mark-Simulacrum would act as Core Team representation for this organization, all other things being equal. |
|
Not convinced this isn't a devtools thing, fwiw, it's not a CLI dev tool but it's still a tool. It's got infra concerns involved but the primary purpose of the team would presumably be improving the experience on the site, not making sure it runs smoothly. |
|
I think it was a mistake to not have an RFC for the release team when we spun it up -- it's one of the things that has been on my mind for something to do next year -- so it's hard to say whether this falls under that scope. I am happy to personally 'represent' a docs.rs team within core team meetings (i.e., help connect issues and such when they arise). I think that it makes sense to have this be a standalone team, similar to crates.io, which "reports in" to infra meetings (like crates.io, and indeed release team, does). I also don't feel like the structure here matters that much, since in practice we've never tried to enforce or otherwise utilize the team hierarchy for decision making. From a website perspective, I think it doesn't make sense to stick either crates.io or docs.rs under infra or release, as both of those are deemed "Operations" |
|
Yeah, standalone makes the most sense to me here. We might consider
something similar for the website if we ever manage to actually spin up
that team.
…On Mon, Nov 18, 2019, 9:38 AM Mark Rousskov ***@***.***> wrote:
I think it was a mistake to not have an RFC for the release team when we
spun it up -- it's one of the things that has been on my mind for something
to do next year -- so it's hard to say whether this falls under that scope.
I am happy to personally 'represent' a docs.rs team within core team
meetings (i.e., help connect issues and such when they arise).
I think that it makes sense to have this be a standalone team, similar to
crates.io, which "reports in" to infra meetings (like crates.io, and
indeed release team, does). I also don't feel like the structure here
matters that much, since in practice we've never tried to enforce or
otherwise utilize the team hierarchy for decision making. From a website
perspective, I think it doesn't make sense to stick either crates.io or
docs.rs under infra or release, as both of those are deemed "Operations"
(https://www.rust-lang.org/governance/teams/operations) which this isn't
quite.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#182?email_source=notifications&email_token=AAMK6SGECTR5U4OCB33DUJLQULHKTA5CNFSM4JM6WQQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEELI3HI#issuecomment-555126173>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMK6SFJ264M5YV2FDDLOSDQULHKTANCNFSM4JM6WQQA>
.
|
|
I should note -- re:RFC for release team, in some sense -- that I think an RFC here would be great, similar to @nikomatsakis, as that would help give the team purpose and define a clear scope to at least start from. |
|
If we're going to do this as an RFC perhaps we should merge this as is first to accurately reflect the status quo? |
|
Actually: could I be added to the docs.rs team as well please? I've been working on the front-end for a while and I'd like to be able to be up-to-date if team meetings are done. |
|
I agree with basically everything @Mark-Simulacrum has had to say :) I think that merging this and then creating an RFC would be "ok", and I think the RFC text could (and should) include that it is formalizing a scenario that evolved over time. It's not like anyone will be "against" the docs.rs team (well, somebody might be, but it's clear we want one). And even if we decided to merge with something else, then we can just adjust the website. |
|
So we just need to fix the conflict and then we merge it? |
QuietMisdreavus
force-pushed
the
docsrs-team
branch
from
0584bd0 to
5325e3c
Compare
|
I've updated the PR to fix the merge conflict (created by #181 - @kinnison is kept on the rustdoc team here), as well as add @jyn514 to the docs.rs team. He's been helping out a lot recently, and has had merge access to docs.rs for a little bit now. I would like to see some kind of confirmation as to whether the RFC to "formally" create this team (and/or perform whatever reorganization is necessary) should be at least drafted before this is merged. I'm willing to work on that draft or open an internals thread, but i want to know how much urgency there is for it, in relation to this PR. |
|
I will do my best to get you an answer this Wednesday at core team triage; I've added it to our agenda. My opinion is that it would be good to get a draft prior to landing this, which I imagine would be an RFC PR posted to rust-lang/rfcs -- it seems pretty clear that in some form we are going to want a docs.rs team so I'm not really thinking a pre-RFC would be beneficial. But I don't feel strongly on this, it's mostly a matter of not wanting to let it slip indefinitely if there's nothing blocked on it (it's too easy to just not do it, and I speak here from personal experience re:release team :). |
|
We discussed this in the core team triage meeting. The summary of that discussion is that we felt that we should merge this PR (as I am doing with this comment), given that it is currently in the subteam of dev-tools status. We expect that in the future, we may want to reconsider this placement, perhaps as part of a wider reorg of the team structure (the questions brought up around crates.io/docs.rs and what that means have been interesting). Thanks for working through the process, and congratulations! |
Left over from rust-lang#182, I noticed it in rust-lang/rust#75619 (comment).
This PR officially creates a new team, the Docs.rs Team, by formally splitting off the responsibilities from the existing Rustdoc Team. While some feature development may have some overlap between these two products, they wind up having totally separate responsibilities in the end.
This creates the following structure:
One open question i'd like to pose is what team the Docs.rs team should be child of. I placed it under Dev-Tools since it's splitting off from Rustdoc, and that's where Rustdoc is currently placed, but it doesn't ultimately seem like the right place for it. The best analog i can think of for an existing team to emulate is the Crates.io team, which is directly under Core.
Another notable thing about this PR is that it involves me stepping down from leadership of the Rustdoc Team (even though i would start leading the Docs.rs Team). My involvement in rustdoc-the-tool has been a lot less recently, both because my involvement in the Rust Project has gone down overall and also because i started doing more with Docs.rs specifically. Guillaume is still quite active with Rustdoc, so he's better suited to having organizational say over the team and the tool's direction. This move should help us both out in working on our respective tools and bringing up new contributors.
This also formally recognizes Pietro's work in keeping up the operations of Docs.rs by adding him as a formal team member. He's been helping out Docs.rs a lot from the perspective of the Infra Team, in keeping the service up and running smoothly.
A question i have about the process of creating a new team - should we create the GitHub teams, issue labels, and the email alias ahead of time, or will the backend piece do that for us?
I'd like to get this merged before approving #181, since it'll let Guillaume have the final say on that.