I’m familiar with most of the individual tools we will be using, as well as the processes in managing development, but what I’m still very hazy about is exactly how you want the workflow to go for the team.
From what I’ve determined right now there seems to be a split between things in the pagure repo and the forum.
Most businesses and/or projects seem to use one as the primary and the other as a backup, so I’m curious how you want the team communication to and collaboration to work.
For example, when you need one of us to do something, will you create a ticket that we can self-assign and then run the ball with? Or will you make a forum post in our subforum which we need to monitor so we can keep up to date on what you need from us?
Since Fedora is a volunteer project, it’s not like we have a daily standup to go over whats on the agenda, so I’m curious how you want the team to collab, so that we can assist you more efficiently and as effectively as possible.
The reason it’s unclear is because it’s undefined. I see there being three categories of work:
- The long-term engagements with other teams that is the primary mission of this team
- Smaller meta-tasks and the like (short engagements with other teams, documentation tasks, etc)
- Covering meetings or other small one-off requests for help
I’ll also point out that categories 2 and 3 won’t just come from me: they’ll also be driven by other members of the team. For example, if JT is supporting the Llama Herder Spin team and he has to miss their meeting one week, he might ask someone else on the team to cover.
#1 is, as we agreed, ticket driven and not self-assigned. #2 seems pretty clearly ticket-driven to me as well. I don’t know how I feel about self-assignment, because I’d hate for one or two people to grab all of the tasks before the rest of the team can. Maybe that won’t be a problem.
As for #3, either a ticket-based approach or a forum post approach seem reasonable. The ticket-based approach is good because it keeps all of the requests for help (whether internally- or externally-driven) in one place and makes it very easy to see who picked it up. The forum approach is good because it’s a little more casual. For example, if no one had been able to cover the Prioritized Bugs meeting last week, I’d have just cancelled it; no big deal.
So I’m fine with either approach. How does the rest of the team feel?