How can we make decision-making more inclusive?

When the pandemic started and many companies have to pivot to dealing with employees working remotely, it struck me how as a distributed, open source project, in many ways we are already better prepared because we do most things async and in written form, by necessity.

Some decision-making processes are synchronous though (namely, meetings). And while we try and find time slots that meet most people’s availability, it seems that meetings currently work better for regular attendees than people who attend infrequently:

  • people who are needed for specific meetings (e.g. ‘FESCo is reviewing your Change Proposal in this meeting’), but otherwise are not regular attendees
  • people who might have been interested in attending, if they can see an agenda in advance

I wonder if there’s a way we can make this better? e.g. some guidelines on running meetings, that workgroups and SIGs can choose to adopt. Some suggestions to kick this off:

  • if you need to hear from someone who does not attend regularly, send them a calendar invite by email
  • if they RSVP saying they can’t make it, try and get questions answered async
  • publish agenda several days in advance, so people interested in specific topics can make the time to attend
  • some guidance on documenting how workgroups/SIGs work e.g. meeting times, where agendas are posted, etc.

Disclosure: this is partly scratching my own itch, as someone juggling internal company work, open source, and a young family, sometimes I can’t even make meetings in my calendar, let alone meetings I only find out I’m needed at 10 mins into that meeting :stuck_out_tongue:

Thank you for reading! Looking forward to the discussion

3 Likes

I think you’re over-generalizing a specific case. (Edit to add: which is not meant to dismiss your concern, but to frame the context)

Most decision making, including by FESCo is asynchronous, done by ticket voting. FESCo doesn’t even discuss most issues in meeting, except when there’s disagreement. In cases where the person needed can’t be available, it’s generally deferred to the next meeting or brought back asynchronously. (In fact, FESCo has an explicit requirement to allow 7 days for voting unless the “fast track” option is requested and assented to).

The only decision-making that I see that’s routinely synchronous is the go/no-go meeting, for what I hope are obvious reasons, and the occasional blocker/FE proposal that doesn’t get resolved in ticket voting.

That said, I agree that sending an agenda ~24 hours in advance is a good practice that all teams should follow. (More than that is probably impractical for a variety of reasons)

I know a guy who’s writing a book with a whole chapter on meetings, but at the risk of infringing on his work, I won’t list all of the advice here. :slight_smile:

3 Likes

Do link to it if there are some info posted :slight_smile:

Yeah, I think in the FESCo case specifically there’s a bit of a disconnect. At least one FESCo member would ping me during the meeting and ask if I can attend, to which my response is generally “sorry, not without advance notice”. So while in theory all can be done in tickets, in practice it seems there’s the expectation to have some sync discussions, /but/ without invites being sent.

I sure hope these are isolated incidents, though from recollection, Workstation WG also sometimes invites external parties to discuss their proposals. These are announced in advance though.

In general I agree that the more we can do async, the better. Of the meetings I have various levels of interest in, all of them works fine for US East Coast, but the times might work less well for Europe and US West Coast, and even less so for APAC (understandable given the distribution of people working on things, but still something to be aware of)

1 Like

Program Management for Open Source Projects

Part of the issue is that people didn’t always see the updates in the FESCo tickets. Pagure doesn’t allow you to subscribe others, so we relied on people subscribing themselves after the ticket was created. Then they could see if it was (likely to) be discussed in a meeting. We’ve addressed this in part by adding “please subscribe to your issues” in the Changes docs and by setting the first person listed as a Change owner as the assignee in the issue. The tooling limits doing much else. The meeting chair is supposed to update each ticket to say it will be discussed at the next day’s meeting. This was done for 2 of the 3 issues on FESCo’s agenda today. I haven’t gone back and looked to see if it was done previously.

The main change I’d suggest, and I can’t remember if FESCo discussed it, is to copy people on the agenda when it is sent. I do that for the Prioritized Bugs meeting (which is another example of synchronous decision-making, albeit a largely symbolic one). I bcc (to keep from offending mailing lists that flag messages based on the number of recipeients) the BZ assignees and the person who requested Prioritized Bug status.

The difficulty with both the “add a comment to the ticket” and the “cc/bcc when sending the agenda” approaches is that it’s a manual process that’s easy to forget.

2 Likes