Add mdbook team

[traviscross]

We need to create a team to maintain mdBook. The people listed here have volunteered. We'll put out a call for volunteers and adjust as we hear more.

TODO: Charter to come.

cc @ehuss @Mark-Simulacrum @eholk @PLeVasseur

[github-actions]

Dry-run check results

[WARN  rust_team::sync] sync-team is running in dry mode, no changes will be applied.
[INFO  rust_team::sync] synchronizing crates-io
[INFO  rust_team::sync] synchronizing github
[INFO  rust_team::sync] 💻 Team Diffs:
    ➕ Creating team:
      Org: rust-lang
      Name: mdbook
      Description: Managed by the rust-lang/team repository.
      Privacy: closed
      Members:
        GuillaumeGomez: member
        Mark-Simulacrum: maintainer
        PLeVasseur: member
        eholk: member
        ehuss: member
        traviscross: member
    💻 Repo Diffs:
    📝 Editing repo 'rust-lang/mdBook':
      Permission Changes:
        Giving team 'mdbook' write permission
        Removing user 'Dylan-DPC''s write permission 
      Rulesets:
          Updating 'master'
            Required approvals: 0 => 1

[GuillaumeGomez]

So apart from ehuss who is leaving the project last I heard and the two PRs from TC which I think aren't enough to be included in a team to maintain a project, no one in this list ever worked on mdBook. Maybe let them contribute first before adding them to the team?

Also, @notriddle and I made a number of contributions because of rustdoc/docs.rs integration we've been working on for... years now? And none of us was included even though (and @ehuss is aware of that) we offered to help with mdBook support for years and I asked repeatedly @ehuss to create an mdBook team to help and offer us an "official" way to help.

Needless to say that I'm extremely disappointed once again that things I'm working on take (big) decisions without consulting big contributors. Last one was the change of dev-tools representative in the council. I really don't like the message it's sending.

[Manishearth]

Needless to say that I'm extremely disappointed once again that things I'm working on take (big) decisions without consulting big contributors. Last one was the change of dev-tools representative in the council. I really don't like the message it's sending.

This is a draft PR and was posted to the devtools team, so I wouldn't say any decision was made yet?

[GuillaumeGomez]

This is an after-thought: "Hello, we decided with people who never contributed to mdbook to create a team composed of one person who left the project and 0 members with experience working on it and without consulting people working on it. Is it ok with you? Is someone interested into joining us?"

Most of the approach is completely wrong.

[Manishearth]

I mean, I don't know who "we" is here. This proposal isn't coming from the devtools team or LC as far as I can tell. I am assuming (maybe incorrectly) that eric is involved and has been collaborating with @traviscross on this.

I don't know how much @ehuss plans to be involved once this team forms. Eric said he was leaving most teams, but he mentioned to me some of his maintainerships would take more time. We should definitely have a concrete idea of what he expects his involvement to be before moving forward.

I think if Eric plans to still be around to charter and build this team up as primary maintainer procedurally he does get to decide how to do that, by putting out a call for participation or something else. If he doesn't plan to be around, then, yes, the decision should revert to the devtools team.

Either way I would like everyone's opinions to be heard here.

[traviscross]

I am assuming (maybe incorrectly) that eric is involved and has been collaborating with @traviscross on this.

This is correct. The steps taken here (opening a teams PR and soliciting volunteers on Zulip, including in the devtools channel), were planned jointly with the others who volunteered originally for the team. These same individuals, Eric, and myself are working together on other related transition activities.

[Manishearth]

Can we get a general shape of the plan? And whether Eric plans to be involved for a while?

I think Guillaume's concern is legitimate to some extent: If Eric is just leaving, then the people who work on it should have a say in how it's evolving.

Perhaps we should use the t-devtools thread you opened to discuss this. I don't have a strong opinion, I just want to make sure that it has a clear path forward and that the people who are actively contributing are heard.

[traviscross]

I think if Eric plans to still be around to charter and build this team up as primary maintainer procedurally he does get to decide how to do that, by putting out a call for participation or something else. If he doesn't plan to be around, then, yes, the decision should revert to the devtools team.

Under your model, given my understanding, I'd suggest devtools handling it then.

[Muscraft]

Given this is being chartered under devtools, shouldn't this get signoff from @rust-lang/devtools

[GuillaumeGomez]

Yes it should. Thanks for pointing it out.

[Manishearth]

Signing off on subteaming as lead, will post to the channel in a bit.

(This is just signoff on there being an mdbook team under devtools)

[Manishearth]

It's already posted: https://rust-lang.zulipchat.com/#narrow/channel/301329-t-devtools/topic/Creating.20an.20mdbook.20team

[Manishearth]

A minor preference I have is for this team to be incubated under rustdoc (a healthy devtools team that has overlap in work, who can probably help with maintenance) until it is stable enough to be its own team.

But the org charg does not matter too much: overall I'd prefer for the rustdoc team to take interest here if they can spare time.

[GuillaumeGomez]

But the org charg does not matter too much: overall I'd prefer for the rustdoc team to take interest here if they can spare time.

We do already (@notriddle and I) and are the ones making the most contributions recently. The bottleneck here was mostly @ehuss' time for reviews.

[Manishearth]

My perception of mdbook is that it is a project without much controversy: the bottleneck is work, not consensus. Is that correct?

For such a project I think if trusted project members are interested in being involved they should be allowed to be on the team without needing to prove interest, as long as they can commit to a certain level of involvement. But we should definitely include the people who have been involved for the last few years.

[GuillaumeGomez]

For such a project I think if trusted project members are interested in being involved they should be allowed to be on the team without needing to prove interest, as long as they can commit to a certain level of involvement. But we should definitely include the people who have been involved for the last few years.

I strongly disagree with that. It's a big project and being on the team also means reviewing code. If they are interested, they're more than welcome contributing to it, and when they're able to navigate the code and by themselves, then we can gladly add them to the team. It would also be unique in the rust organization. The only cases where we add people without prior experience is either when a project is "dead" (ie no more active contributors, which is not the case here) or when it's a new project (not the case here either).

[GuillaumeGomez]

My perception of mdbook is that it is a project without much controversy: the bottleneck is work, not consensus. Is that correct?

Sadly no, we do need to discuss some features, mostly around the rustdoc/mdbook integration. Discussions already started but stalled as @ehuss was mostly unavailable.

[Manishearth]

The only cases where we add people without prior experience is either when a project is "dead" (ie no more active contributors, which is not the case here) or when it's a new project (not the case here either).

I feel like we've done this before though now I can't remember where (probably rustup?)

But also I think you've misunderstood what I said there. I didn't mean to say that the people working on the project should be forced to accept new collaborators. I was trying to highlight it as an option I think they should (not must) consider and be okay with.

I agree that the primary deciders of the fate of this project should be the people currently active on it.

If the project is struggling with maintainers (which was my impression of it), I think the project should (not must) be open to accepting people who have expressed interest. Often this takes the form of a foo-contributors team but for something like mdbook it's small enough that I'd probably just want it on the main team.

Generally I think this sort of thing works well to rejuvenate a team.

[GuillaumeGomez]

If the project is struggling with maintainers (which was my impression of it), I think the project should (not must) be open to accepting people who have expressed interest. Often this takes the form of a foo-contributors team but for something like mdbook it's small enough that I'd probably just want it on the main team.

The problem is that there is one person officially in charge of mdbook: @ehuss. I can press the "merge" button, but since I'm not officially in charge of the project, I don't know if it would be acceptable or not, therefore I don't. Hence why I asked @ehuss more than a year ago to create an mdbook team so we could remediate to the main issue of mdbook: only one person to review.

A good example to illustrate this situation: rust-lang/mdBook#2706. I reviewed it and the changes look good. I can press the merge button, but am I supposed to? So at the moment, the review capacity is one person and until there is a formalization of the mdbook repository, I'm not sure what to do. I could simply put everything aside and just start to review/close/merge things, but that seems like a process defect.

So just to be clear: I want an mdbook team, just a team where all members already know the codebase (which is completely possible based on the recent contributors with >= 20 commits or 10 merged pull requests).

[traviscross]

As mentioned in #2652 (comment), I think this is a devtools matter, so let's close this draft PR pending devtools making a determination on handling.