Set up mentorship team "properly" #1671
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
traviscross
force-pushed
the
TC/fixup-mentorship
branch
from
1b64924 to
48dbc02
Compare
Member
|
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 On the other hand, I understand if you want to keep things unified and have the same structure for all (non-marker) teams. |
traviscross
force-pushed
the
TC/fixup-mentorship
branch
from
48dbc02 to
8f3a3b7
Compare
Contributor
Author
|
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. In this case, the repo would probably include that charter and then link to the gsoc repo and maybe the I pushed an update to change the Zulip stream to 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 |
Member
|
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. |
Kobzol
reviewed
Mar 2, 2025
traviscross
force-pushed
the
TC/fixup-mentorship
branch
2 times, most recently
from
27e7676 to
2670a81
Compare
Kobzol
approved these changes
Mar 2, 2025
Member
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. |
Contributor
Author
|
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. |
This was referenced Mar 10, 2025
Member
|
I am a strong -1 on adding the repo here. It is going to be empty (and if we eventually find something to use it for, we can add it), and an empty repo is just pointless (and it is a net negative because it will be around "forever" - even if eventually archived- and has some kind of expectation that there "should" be something there). Honestly, if we need a link for the website, it should just go to a zulip stream right now. |
Contributor
Author
Member
|
Essentially, I agree with @davidtwco that Forge is the better place for the charter and contact info. So, otherwise the repo will be empty. I'm supposedly a co-lead of this team too (granted @Kobzol is the star here, but this is an area that does matter to me). I haven't talked with @Kobzol about this issue in particular, but I'm voicing my thoughts in this thread. I'm very aware that Jakub conceded initially, but both @davidtwco and now I have dissented. |
Contributor
Author
|
OK. It sounds like the mentorship team should discuss and decide where they would like to host the documents related to the team itself, including the team's charter, information about the team's meetings and otherwise about how to contact the team, the team's policies and other team meta-documents etc., and where the team would like its entry on the website to link to in that regard. Let me know what you both agree to after that discussion, and I'll update this PR. The project makes many resources available to teams, including GH repositories, existing shared repositories such as the forge and the calendar, and other such things, and, in my view, our standing policy is that teams are able to avail themselves of these at their discretion and as is reasonable and appropriate. As a project matter, probably I think it's healthy for us to want teams to publish somewhere the kind of information mentioned about the team itself, and correspondingly to include all teams on the website, and to have the website link to that information for each team, but as we have no specific policy about how that is done, this is I believe an internal matter for the mentorship team, and whatever you both want to do will be the answer. |
Member
|
We had a brief discussion with Jack about this. A couple of points:
We can always create a repository later if we need to. But we think that creating one just for the sake of it isn't worth it. And I suspect that the same will hold for several other small-ish teams. |
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". 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 in particular an entry on the `rust-lang.org` website for the team.
traviscross
force-pushed
the
TC/fixup-mentorship
branch
from
2670a81 to
ac2f6f8
Compare
Contributor
Author
|
OK, easy enough. PR commit updated accordingly. |
Dry-run check results |
Kobzol
approved these changes
Mar 13, 2025
jackh726
approved these changes
Mar 13, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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