-
-
Notifications
You must be signed in to change notification settings - Fork 0
PMing for the Guides Team
Guides: Meeting Agenda and Minutes - pretty much everyone on the team should be assigned to this, but especially PMs
Team Questions - if someone has a broader question about the Guides team, it should be answered here. This issue should also be reviewed for any information that we should consider putting on our Wiki.
Recruit Volunteers for Open Roles - and similarly, any open role issue on the team. The PM lead is the first point of contact for any new volunteers on the team and they should be actively thinking about what recruitment the team needs to be doing.
Onboard & Offboard: Product and Offboarding and Team Members Cleanup - I will cover this in a bit more depth when I talk about Onboarding & Offboarding
As the PM (especially lead PM), it is your responsibility to set the agenda for weekly meetings. This means you have to keep track of where the team is at with its current work, prioritize points for discussion, and keep the meeting (roughly) on track. The best way to think about it is to remember that this is your meeting! Consider what is most useful for the team to discuss to move progress forward, and what can't be resolved at other times throughout the week.
The agenda should be started at the close of the previous week's meeting. It doesn't have to be completely filled out, but putting the comment down allows people to add agenda items throughout the week.
Agenda Items typically come from 3 sources:
-
Work in progress: items that come from work agreed upon in a previous meeting
-
Priorities from the Org: typically these will be highlighted by Bonnie, either in the meeting agenda or through Slack
-
New priorities established by the PM team - if new issues have come up, or you're transitioning to a new part of the project and you need to discuss it with the rest of the team
Always start with your most pressing issue first in case you run out of time. If you do run out of time, copy the remaining agenda items to next week's agenda. When possible, link issue numbers or documents that you're hoping to review so everyone has access to it without needing to search for it.
Ideally, the person leading the meeting is not also taking minutes, but this isn't always possible.
Meeting minutes should record:
- decisions made and why they were made (in case you forget why you did something later down the line)
- future action items (especially if an issue has not been created for it yet)
I would recommend taking meeting minutes on a non-Github platform and then transferring them at the close of the meeting. The risk of taking minutes directly in a GitHub comment is that if you accidentally close it without saving, your minutes are gone. If you do this, though, get in the habit of transferring them immediately after the meeting ends! Other people on your team will need to reference them if they forget what they were supposed to be doing.
Meeting minutes are stored in https://github.com/hackforla/guides/issues/136 If the issue gets too long or unwieldy with all of the comments, close the issue and open a new one. Copy the description of the previous issue into the new issue, and put a link at the bottom to the previous issue under 'Past Agenda Issues.'
If you are meeting on a one-time basis, keep the meeting minutes in the same issue as the regular meeting minutes. If you are creating a separate, standing meeting time, create a new issue to track its minutes and agenda. (ex. The Website Team's Meeting Agenda Issues)
Instructions for Creating New Meetings can be found in Zoom Setup. Essentially, the process boils down to finding a time when no other team is using a Zoom room, putting your own meeting down, and creating the invite through the Zoom account. I would check with Bonnie if you're doing this though, as you'll likely also need to add the meeting time to VRMS.
Our primary project boards are:
All of the work that the Guides team does lives here. Any issue you create that is not a guide should go on this board.
Overview of Columns on this Board:
-
Weekly Tasks: things to address weekly (roughly)
-
Ice Box: issues with dependencies - these issues cannot be resolved until their dependency is dealt with. When the dependency is resolved, the label is removed and the issue is added to the prioritized backlog
-
Prioritized Backlog: most new issues created will go here. The backlog is prioritized because it should be organized by Milestone - you can drag cards around on the board to arrange them in the correct order.
-
In Progress: issues should only be here if someone on the team is actively working on them. If nobody is working on them, or no progress has been made in the past 2 weeks, reach out to the assignee using the template in Offboarding & Team Members cleanup. If it's been over a month, unassign them from the issue and return it to the prioritized backlog.
-
Questions/Review: this work has been completed by someone on the team, and is waiting for review from the PM lead or Bonnie.
-
Done: closed issues.
There are many issues on this board that are no longer relevant simply because they're so old. I'd consider putting a process in place to close old issues so the team can focus on the most immediate priorities.
This board tracks Guides in the Knowledgebase-content repo. If it is not a guide, it probably does not belong here.
This board exists to give the Guides team a sense of where each Guide is in the guide-making process. New guide issues should be added to the 'Needs to be Triaged' column. From there, they will most likely be sorted into the 'Prioritized Backlog' column, unless they are ready for review.
This board tracks ALL of the guide issues, not just the ones in the COPs. The columns on this board are currently a mess because they are a legacy of the previous guides tracker. That tracker was meant as a more externally-focused board for the HfLA community's use rather than the Guides team's. Once all of the issues have been transferred to the KB-C repo, you might decide that this board is obsolete, or have a different discussion on how to best organize it.
Document everything like there's a chance that tomorrow the entire team could be wiped out, and someone else has to pick up where you left off without being able to contact anyone. Make notes of progress and decisions made in the issues themselves and communicate there whenever possible. Slack is great, but anything stored there disappears after 3 months.
When someone on the team needs access to a file, never request access to that file directly. Bring it up in a comment of an issue, or raise it with Bonnie during the meeting. The problem is not 'access to this particular file,' it's whether you might not have access to something that you should. So by working it out with someone who can see where that file exists, you can get the right permissions and hopefully avoid future issues.
If an issue can be broken down into discrete tasks that take at least 2-3 hours on their own, create an epic instead. Turn each task into its own issue linked to that epic.
PMs
The guides team is always recruiting PMs so that volunteer PMs in time zones across the globe always have a project time that's accessible to them.
UI/UX
It's not a high priority, but the Guides team is looking for a UI designer to clean up our style guides, make our presentations pretty, and design a new logo for us. We haven't had a UI designer on the team in close to 2 years.
UX Research
Rhoda is our UX Research lead, reach out to her when the team is prepared to focus on Research again. Eventually, the rest of her team will need to be recruited.
Engineering / DevOps
The Guides team typically doesn't handle this stuff ourselves so we don't really recruit for these roles.
New volunteers interested in the Guides team should reach out to the PM lead over Slack (this is the instruction given in our wiki, so make sure it's up-to-date with the appropriate lead). The PM lead should respond with a short description of the guides team, what we're working on, and the responsibilities for the role we're recruiting for. I'd recommend coming up with a template for this.
It's also good practice to ask if they're shopping around for different teams and are just looking to sit in on an initial meeting, or if they've decided on the Guides team and can be onboarded immediately.
If they're a PM, most of the information needed for Onboarding can be found in the PM roster, so much of the onboarding process can be done ahead of time if you're short on hands at the meeting.
Ideally, the lead PM handles running the meeting while another PM completes the onboarding process with the new volunteer, so interruptions on time are limited to when Bonnie needs to add them to 1Password.
Start new volunteers with small tasks to get a sense for their familiarity with GitHub and their ability to get work done quickly and efficiently. If there's nothing that jumps out for them to work on, ask them to work on a guide!
Ghosting
If someone ghosts, the standard procedure for removing them from the team is outlined in Offboarding and Team Members Cleanup. This includes reminders for updates over a period of several weeks, in case they had a temporary interruption in their ability to contribute to the team. After about four weeks, they will be removed. If they want to return to Hack for LA at another time, they can be re-onboarded.
Onboard & Offboard: Product is the issue for Onboarding and Offboarding all team members. When someone joins or leaves the team, copy the appropriate template to a new comment and add their name to the top of it.
When team members are offboarded, they should still maintain read access to most things, but not write access.
The Wiki is a working document and we would love to improve it. Please compile any questions and suggestions you may have and submit it via creating an issue.