Meta Meeting Notes
This document contains meeting notes from the Meta working group.
Written by: @spastorino
- What problems do we want to solve from a compiler team member perspective and from a contributor perspective?
- Help to grow the team by ensuring that we engage people who’ve started to get active in rustc?
- Provide a source of people who can help implement things without needing as much mentoring?
- What does it mean to be a journeyperson?
- You know something about the compiler?
- People willing to commit some time to help run things
- What is the role of a journeyperson in onboarding new compiler contributors?
- r+ rights?
- Start to do reviews?
- What responsibilities should a journeyperson have?
- Are journeypeople members of the team or is a journeyperson role considered a stepping stone toward being a member of the team?
- What are the qualifications and expectations for a member of the compiler team?
- What’s the difference between journeypeople and team members?
- Full members know >1 area?
- Or full members know enough to independently lead a WG in some area?
- What is the process for becoming a journeyperson?
- Should compiler team members nominate new journeypeople and then confirm it with the rest of the team?
- Is there some formal mechanism for that?
- Should compiler team members have a responsibility to mentor their proposed journeypersons through their new responsibilities?
- What is the process for transitioning from a journeyperson role to full membership?
- Same process as already exists for becoming a full member?
- Is there an ettiquette for journeypeople?
- What about team members?
Written by: @nikomatsakis
Purpose of meeting:
- Clarify the “scope” of the meta working group.
- What problems does the meta working group aim to solve?
- What problems do we want to avoid creating? (e.g. bureaucracy, administrative overhead)
- Discuss working group “bootstrap process”
- What should each working group define?
- What structure should a WG “check-in” have?
- Can we produce a “WG Template” that I can then pass around to folks to fill out?
- What are the most actionable ideas and can we rank those?
- Which ideas would be better suited for more “discussion meetings”?
- Steering meetings? Or should we use those for something else
Working Group Components:
- Zulip Stream(s)
- Zulip User Group (
- GitHub Team? Someway for people to get notifications
- GitHub Labels
- Contact points:
- Compiler team liason — who will present
- Maybe others that you can ping on Zulip to ask questions
- Across team:
- Some kind of table summarizing WGs
- Membership (default):
- We want to avoid any sort of formal membership to a working group. Instead a wg has leads and interested folk can subscribe to it to receive notifications on GitHub issues and in Zulip.