Meta Meeting Notes

This document contains meeting notes from the Meta working group.

2019-02-28: Meeting

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?

2019-02-21: Meeting

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 (WG-compiler-foo)
  • GitHub Team? Someway for people to get notifications
  • GitHub Labels
  • Contact points:
    • Leads
    • 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.