# MIP41c4: Facilitator Onboarding (Subproposal Process) Template ## Preamble ``` MIP41c4-SP#: # Author(s): Contributors: Tags: template Status: Date Proposed: Date Ratified: ``` ## Sentence Summary ## Paragraph Summary ## Specification ### Motivation - Why are you applying to become a Facilitator? ### Core Unit ID - Specify the Core Unit ID. - This element specifies which Core Unit you are proposing to onboard to as a Facilitator. ### Facilitator Account and Information - This element must contain the Forum name of the Facilitator, as well as other names and IDs in Maker related communication channels. Additionally it must contain the Facilitator's Ethereum address used for Budget Implementation control and other authorizations. Entities may be designated as facilitators, but only communications from listed and approved authorized accounts may initiate the use of facilitator powers. ### Facilitator Commitment - The Facilitator Commitment is a detailed description and plan of what the Facilitator plans to do in order to achieve success for the Core Unit. There is a lot of flexibility in what a Facilitator can write in their commitment, including organizational structure and theory, plans for the budget, hiring and infrastructure plans, etc. - The Facilitator commitment should also contain targets and goals that can be observed by Governance, if appropriate. This helps Governance to see whether the Facilitator is living up to their expectations. - A crucial part of the Facilitator Commitment is clear commitment to transparency. The Facilitator should commit to an effective plan that will allow Governance and other stakeholders, such as contributors contemplating doing work, to gain direct insight into what is being worked on and who are taking care of what responsibilities. ### Succession Plan In the event this facilitator is no longer active (for any reason), state which individual person or role within the Core Unit will serve as Interim Facilitator. If this is unnecessary (e.g. the Core Unit has multiple facilitators), state the reasoning specifically. Note: Updates to a Core Unit's Succession Plan do not require a governance vote if the updates are: - Publicly documented. - Proposed by a facilitator of that Core Unit.