Well I got a much larger response than I expected. Instead of 3-4 volunteers, 15 people submitted their availability. As you can imagine, this makes scheduling a meeting very difficult. For any particular time slot, about half of the volunteers couldn’t make it. Since I intended the meeting to be an open discussion, splitting it across multiple meetings doesn’t seem very helpful. So we’ll start here and work asynchronously how it goes.
First, I’ve sent emails to everyone asking a few questions about your interests, skills, and experience. I sent this to everyone who used their Fedora account when submitting availability (and everyone whose Fedora account I could figure out from the name they used). If you did not receive this email, please let me know.
So here are the open questions we should solve. For things that I have a weak opinion on, I’m keeping it to myself initially. When I have a strong opinion, I’ll pre-share it. However, that doesn’t mean it’s set in stone.
I hold weekly FPgM office hours. Do we want to use those or have a separate team meeting? (Any training meetings will be done separately)
Do we need our own chat channel? If we want one, it will be on IRC/Matrix (or maybe just Matrix and we’ll move it to the Fedora homeserver once that is in place.)
Should we use a mailing list or a Discussion category?
- How do we track work? Taiga? Pagure repo?
- I have a Taiga board he uses to his work, but it also contains work that can’t be assigned to this team, so it may not be good to reuse this. I anticipate most of the work being more task-like in the sense that they have done and not-done states, which suggests a Pagure repo is the right approach.
- How should other teams as for help?
- If we go with a Pagure repo, I think the way people ask for help is to open an issue on that repo. We can create a template that prompts them for relevant information. When a team member is assigned, we assign them on the ticket. The downside is that it means teams will remain open for a long time (because we want to see who is assigned where). Alternately, someone taking the assignment closes the ticket and we maintain a doc that lists who is assigned where. That information shouldn’t change frequently, so that’s not a significant burden.
- How do people get assigned to a request?
- I don’t want it to necessarily be “the first person who claims a help request gets it” because that’s not fair to people who aren’t online when the request comes in. I think the right approach might be for me to match the team’s needs with the skills and interests of PgM team members. This way, we’re maximizing the goodness of fit. On the other hand, I don’t want to create bad feelings if someone doesn’t get matched with a request for a while (I’m not sure there will be enough work to go around), so if anyone had better ideas, I’d love to hear them.
- What else do we need to figure out early that I’m forgetting?