Set up mentorship team "properly"

[traviscross]

To facilitate getting out a blog post, we added the mentorship team (previously chartered under the name "internship team") under the name "mentorship-programs". Let's now make some edits to set this up more "properly" (in my view, of course).

First, let's rename it to just "mentorship". Probably I understand the hesitancy to claim such a broad mandate by calling it that rather than "mentorship-programs", but it just seems unlikely to me that we'd ever have both a "mentorship-programs" team and a "mentorship" team, so we should just use the shorter name. (My guess is that if we ever wanted some other kind of mentorship, it's more likely that this team would expand its mandate than that we'd add a second team.) If that really makes us uncomfortable, then probably I'd suggest going back to the "internship" name, as that is actually rather unambiguous here.

Second, as we discussed on the chartering thread, let's not include the mentors as members of the mentorship team and instead break that out into a separate marker team. It's good for teams to have a clear charter and purpose for which the members are responsible. If there really is a divide where the mentors aren't responsible for the work stated in the charter of organizing and administering this program, then the membership should be split out. That is, we should ask, "who would be on an FCP for a given decision?" Having such clarity, e.g., helps the council in cleanly delegating matters to teams, which we prefer doing, rather than having to specify a delegation to just the leads.

In this PR, that marker team is marked as a subteam of T-mentorship. I don't see us doing this anywhere else in this repository -- making a marker team a subteam -- but neither do I see it documented as not working, and it seems appropriate in this case, so we'll see if it passes CI.

Third, let's set up all the other normal accoutrements of such a team, including a repository for the team's documents and website, a Zulip stream and group for the team itself, etc.

---

(It goes without saying, I hope, that this is simply a proposal for what would clean this up a bit, in my view -- in the spirit of avoiding organizational debt -- and seeking by this PR input from others. I helped draft the charter, and I'm interested in how we set up teams generally in a consistent way as a council matter, but I'm not a member of this team or otherwise involved.)

cc @Kobzol @jackh726 (leads) @jamesmunns (council rep) @Mark-Simulacrum

[Kobzol]

I agree with the renaming and the split, but I don't think that we need a separate repo and Zulip stream, because the gsoc repo and #gsoc/private stream already kind of fulfill that role.

When I was moving all of our repos under the team repo, I noticed a lot of pretty much empty repos that were created for some team or working group, but weren't ever used. I think that it makes sense to only create these repos on demand, when the team actually wants one. I also don't see us doing FCP votes anytime soon :)

On the other hand, I understand if you want to keep things unified and have the same structure for all (non-marker) teams.

[traviscross]

Yes, that's basically the tradeoff. Here's what I'm thinking. It's good for each team to have a repo for the team itself (i.e. separate from the work products of the team, e.g. compiler-team vs rust-lang/rust). If nothing else, this is the right place to put the team's charter, to describe how to contact or interact with the team, and to link to the various things the team does or manages.

In this case, the repo would probably include that charter and then link to the gsoc repo and maybe the #gsoc Zulip stream. It seems fine to me if that's all this repo ever does. The point is that it gives us a canonical place to link to for these things, e.g. from the rust-lang.org website.

I pushed an update to change the Zulip stream to #gsoc, since I see now that's already there and in use.

If you really don't want the repo, let me know and I'll pull it out, but probably it does seem right to me that it should exist. We named this team "mentorship" rather than "Google Summer of Code", so it would seem strange to me if the entry on the website linked directly to rust-lang/google-summer-of-code for the team or that the charter was put there. It seems better for that repo to be one of the artifacts on which the team works, and to separate off the repo for the team itself.

[Kobzol]

Ok, fair enough, I agree with that reasoning, let's keep it then.

I think that eventually we might want to rename the gsoc repo, e.g. to "mentorship-project-ideas" or something like that, but even then it's something else than a repo for the organization of the mentorship team, these two things are separate.

[davidtwco]

Yes, that's basically the tradeoff. Here's what I'm thinking. It's good for each team to have a repo for the team itself (i.e. separate from the work products of the team, e.g. compiler-team vs rust-lang/rust). If nothing else, this is the right place to put the team's charter, to describe how to contact or interact with the team, and to link to the various things the team does or manages.

I disagree, I think we should centralise these somewhere like forge.rust-lang.org. t-compiler is moving away from its own repository and we have lots of abandoned repositories for short-lived projects/working groups. It's a lot easier to keep things up to date and find things when you know to just go to the forge and browse.

[traviscross]

As it is, I agree we should have a central place that people can start. It seems fine to me, though, if that then links outward to the sites and important elements of those sites (like charters) for each team.

Some teams have a lot of documents, policies -- the minutes to meetings -- all sorts of things. I see drawbacks to trying to manage this all centrally for all teams as compared to letting each team manage its piece, and neither do I really want teams to have to break this apart so as to manage some of their documents centrally and the rest on their own sites.

But at the end of the day, it's just kind of a factoring question -- either is probably fine if we commit to it -- and essentially boils down (as many things do) to how much we like monorepos.

It doesn't seem like we need to solve that to merge this PR. What we do today is that teams have their own sites. If we decide we want to refactor that into a monorepo, we can merge the one for this into it then like we'd need to do for those of many other teams.