>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3518607. --> Reported by: [mradcliffe](https://www.drupal.org/user/157079) >>> <h3>Meeting Minutes</h3> <p>The Mentoring Working Group (MWG) charter has been formally accepted.<br> We are focusing on our immediate needs in this meeting.</p> <h4>In Attendance</h4> <ul> <li>Tim Lehnen 'hestenet'</li> <li>Rachel Lawson 'rachel_norfolk'</li> <li>Chris Darke 'ChrisDarke'</li> <li>Matthew Radcliffe 'mradcliffe'</li> </ul> <h4>DrupalCon Timeline Documents</h4> <ul> <li>Chris is working on three timeline documents: <ul> <li>DrupalCon planning: schedule prior to the conference</li> <li>DrupalCon event: schedule during the conference</li> <li>DrupalCon feedback: schedule after the conference</li> </ul> </li> <li>This is driven the DrupalCon steering committee.</li> <li>Updates to documents need to end up in Meghan's &ldquo;Event Bible&rdquo; and Kuoni's equivalent.</li> <li>We recognize that this information has existed in various formats, but legacy knowledge is required to remember where it is.</li> </ul> <h4>Document Store</h4> <ul> <li>Chris brought up the many places that we store Mentoring documentation: google drive, DA google drive, drupal.org as well as difficulty of finding both information for those searching for a mentor and those searching for mentoring documentation. <ul> <li>Tim mentioned a growing precedent for user-facing documentation to be available on drupal.org and internal documentation to livew on GitLab via GitLab pages.</li> <li>There was shared enthusiasm about GitLab pages for internal documentation and linking to those from existing drupal.org documentation pages.</li> </ul> </li> </ul> <h4>Mentoring Working Group Initial Plan</h4> <ul> <li>Our charter and the initial MWG is to get us started so that we can figure out membership and terms next.</li> <li>We need to set a date to have governance finalized. <ul> <li>Tim suggests after Vienna 2025 and we use this time to see what works, gather feedback from Core Mentoring Coordinators (CMC).</li> </ul> </li> </ul> <h4>Communications and Decisions</h4> <ul> <li>Question was asked &mdash; At what point does everyone involved make a decision? Entire mentoring team? CMCs? MWG?</li> <li>Tim recommends this should default to coordinators. And all mentors act in an advisory role to keep communication open, but not blocked. Similar to other working groups.</li> <li>Requests for feedback asked in Mentoring Meta and in issue queue. <ul> <li>Mention of Cunningham's Law essentially &ldquo;correct us when something is wrong&rdquo;</li> </ul> </li> <li>Models for order of operations (all apply) <ol> <li>Pose question/decision to gather feedback back to CMCs and MWG.</li> <li>MWG proposes to CMCs and then to Mentoring team.</li> <li>MWG makes quick decision followed by feedback and revision.</li> </ol> </li> <li>We change to making decisions by consent rather than by unanimous consensus.</li> <li>Matthew has tried to be completely open to the mentoring team about almost everything and every procedure by creating issues and adding to the Mentoring meta agenda.</li> </ul> <h4>Mentoring Working Group Membership</h4> <ul> <li>Tim mentioned the recommendation in moving in the direction of renewable terms with affirmative consent of the person and affirmative consent of coordinators.</li> <li>We should have a way to trigger a roll-off of responsibility.</li> <li>Rachel: We recognize that in reality the people who are doing things and turning up are the the ones filling these roles.</li> <li>Biggest risk: to busy to figure out how to get help or train/mentor someone before burn out.</li> <li>We should consider a dedicated "second" for each member and improve mentoring mentors into our process.</li> <li>This will help with having access to materials, system accounts.</li> <li>Regarding choosing people to add as CMCs: <ul> <li>The "one" big issue has been problematic to review.</li> <li>Once we have our governance by-laws we can read them, make the decision as the ones to be accountable for it, and then do it, RTBC it, and update the prior maintainers list.</li> </ul> </li> <li>We need to work on identifying our strengths as CMCs. <ul> <li>CMCs have many roles, but we should not feel need to do all the roles.</li> <li>Rachel: This provides a mentoring opportunity to learn a new role</li> <li>Matthew: Our coordinator role page needs work (there's an issue for that)</li> <li>Tim: scheduling and reminders are important for updating documentation. Automation helps.</li> </ul> </li> </ul> <h4>Mentoring Working Group By-Laws</h4> <p>Our by-laws are the operating rules/procedures that are not in the charter and provide an easier way to change those procedures.</p> <ul> <li>Tim mentioned a working group that has a good example, but could not remember which one. Maybe the Community Working Group (CWG)?</li> <li>By-law suggestions: <ol> <li>List out the difficult decisions that we have had to make as CMCs.</li> <li>Come up with the procedures to handle these decisions.</li> </ol> </li> </ul> <h4>Miscellaneous</h4> <ul> <li>Tim: if you need official working group association accounts, official drive, or something else, please ask Tim.</li> <li>Chris asked about handling difficult decision during DrupalCon. This was discussed, but nothing proposed.</li> <li>Perhaps a shared calendar for CMCs to know about each other's schedules.</li> <li>Individual channel managers for Mentoring coordinators/leads and mentoring team Slack channels.</li> <li>We talked about the Drupal Contribution web site, Member Platform, and automating calendar reminders for contribution events and needing to do something.</li> </ul> <h4>Action and Future Discussion Items</h4> <ul> <li>Matthew to post minutes to Mentoring issue queue.</li> <li>Meetings: <ul> <li>We will meet weekly until we are situated to meet every other week for the initial MWG.</li> <li>The current time works for everyone (Thursdays at 17:00 UTC)</li> <li>Tim will setup a reusable zoom link.</li> </ul> </li> <li>The Mentoring Meta is next week (Wednesday, 9 Apr 2025 20:00 UTC) with an agenda.</li> <li>Proposals for document store.</li> <li>Proposals for by-laws and policies.</li> </ul>