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?
If I may suggest something as this is a new initiative as Ben mentioned, it will be hard to determine how everything should work especially that till now only Ben has been working as PgM without distributing and delegating work. In order to figure out way of working I believe we should approach this together and review two sources of knowledge, all materials here Fedora Program Management :: Fedora Docs and second the most important Ben itself, to tell us how it looked so far from practical point of view and some lessons learned. I’m thinking here about one or two sessions with coffee or beer just as open discussion and then ideas should come naturally. The challenge can be finding some common free slot for the discussion but finally, we are PgM
I certainly encourage everyone to read through the existing docs and ask questions on Discussion. It’s important to keep in mind that what I do isn’t necessarily what you’ll do, particularly when it comes to providing direct support to other teams.
I’d like to have another open chat with all of us, maybe around Nest? In the meantime, asynchronous discussion here is probably the best route.
reading documentation I think is clear for everyone. But I think we need a regular exchange as a team.
If I may speak now of me, I do not know yet all teams and possibly contact persons.
I think we need in the beginning a more intensive exchange until all team members are on the same level.
As an example, two issues have now come in. For me, it was unclear until today how the procedure is now and who is working on what.
If I understood correctly, you have been the only PGM so far I think it is important that we bring your knowledge and experience to the team.
Get more insider information from you maybe in one or two sessions as Pawel also suggests.
Well if everyone on the team realizes it’s not a competition, and that we all are here to pitch in idk if it’ll be a problem. I know for myself, sometimes I’ll find myself with a bunch of time over a week or two, and then little time the next week. So I may grab a bunch of things if I can handle them because I know I wont be able to pitch in that much the following week or two.
I’m fine with you assigned tasks out to us, if there’s one I’d like to take I can just leave a comment saying so. My only concern then would be that Im making more work for you to ‘approve’ me taking a ticket, instead of just taking it myself.
I can go with either, as long as there’s a SOP that we all are on board with. I think I primarily prefer tickets because I find it easier to track than figuring out which forum threads I really need to follow closely. I’ve gotten so used to using Jira for internal Communication at so many places that it’s just natural for me to gravitate towards that… but I’m up for whatever best for you. As your the team lead I don’t want to make things harder on you to manage the team.
My primary concern is knowing where the source-of-truth is for keeping tabs on what I’m needed to assist with. Doesn’t really matter to me where that happens to be, as long as i know where it is.
Yeah, I’m wondering if this falls squarely into “we’ll deal with this problem when it’s actually a problem” category. From your comments, I’m inclined to think it does.
If no one objects, let’s go with “put things in tickets and let folks self-assign (with the exception of long-term engagements)” approach.
just as open discussion and then ideas should come naturally. The challenge can be finding some common free slot for the discussion but finally, we are PgM 
