#106 Improve WG organization
Opened 2 months ago by aday. Modified 19 hours ago

The WG is suffering from low attendance at its meetings, and we discussed various ways to improve this at today's meeting. Suggestions included:

  1. Require members to send their regrets if they can't make a meeting
  2. Create a private mailing list (or equivalent) for the working group
  3. Assign a WG permanent chair, rather than having a rotating chair
  4. Send a definite agenda out in advance of each meeting
  5. Document the meeting schedule on the wiki

Some of these points are probably more to do with improving WG organisation in general, and making it into a more cohesive organisation.

The meeting seemed positive regarding point 1. There was some uncertainty regarding point 2. It's unclear what the consensus was on points 3-5, or if there are other actions we should consider.

Personally, I'd be in favour of all 5. I'd also be strongly in favour of us having video calls rather than IRC meetings.

Points in favour of 2 include:

  • It would prevents us from spamming fedora-desktop list with mails that are only relevant to WG members
  • It could help WG members to follow WG business
  • It would give members a way to communicate privately with one-another; this will mostly be relevant when we need to send regrets

Metadata Update from @catanzaro:
- Issue tagged with: meeting

2 months ago

Another improvement to consider: ensure that each ticket is updated with a summary after it is discussed in a meeting. Right now it doesn't always feel that tickets reflect what has been said in our meetings.

I'm the chair of the GNOME Foundation Board of Directors, where I think we generally have efficient meetings. The GNOME board has a slightly different purpose, but there are some practices that we use, which could be considered by the workstation WG:

  • video calls
  • a permanent chair
  • a secretary who is responsible for taking minutes and updating issues after each meeting (this is particularly important for tracking action items)
  • the chair decides what goes on to the agenda
  • the agenda is sent out in advance, with instructions on what participants need to do to prepare for the meeting
  • only tickets which pass certain criteria get on to the agenda: they must be clear, sufficient background needs to be provided, and they must clearly fall under the remit of the board (or, in this case, the WG)
  • tickets have due dates assigned if there are relevant deadlines
  • every ticket is required to have an assignee
  • we have a kanban, which we use to track and prioritise upcoming tasks

In general our goal is to keep meetings short and to the point, and to push the work out of the meetings and into preparing each item.

Proposal 1:

  • Elect a chair, vice-chair, secretary and vice-secretary. We should probably discuss the term length, but my initial suggestion would be 6 months.
  • Document the responsibilities of the chair on the wiki:
    • Set the agenda for each meeting, and send it out to fedora-desktop in advance
    • Set the time and date for the meetings, and document the meeting schedule on the wiki
    • Act as chair for each meeting
  • Document the responsibilities of the secretary on the wiki:
    • Record meeting attendance
    • Record minutes of each meeting (don't have to be detailed)
    • Update the issue tracker after each meeting: updated existing issues, if necessary create new ones, and record action items
  • Document the responsibilities of the vice-chair and vice-secretary on the wiki: to stand in for the chair and secretary, if they're unavailable

Proposal 2:

  • Switch from IRC to Bluejeans video for meetings

Proposal 3:

Apologies for somewhat taking over this issue...

I don't think we need a dedicated secretary if we continue with IRC meetings, since the minutes take themselves if the chair uses meetbot commands when possible. Would be needed if we switch to BlueJeans, of course.

I don't think we need a dedicated secretary if we continue with IRC meetings, since the minutes take themselves if the chair uses meetbot commands when possible. Would be needed if we switch to BlueJeans, of course.

Right, although it might make sense to have someone whose responsibility it is to update the issue tracker after each meeting (could be the chair, a secretary, or another role).

Anything that can automate, or help streamline, the Workstation edition status dashboard, the better.
https://docs.fedoraproject.org/en-US/project/dashboard/

I am not a fan of video meetings. I feel like it gives a fair bit of advantage for native English speakers and I don't think I would be able to participate as effectively any more.

IRC meetings are also much more inclusive where the rest of the community can hang out in the meeting channel and see what's going on and maybe drop a comment if they are interested in a particular topic. Often we've had comments from e.g. mattdm and sgallagh etc during IRC discussions.

I am not a fan of video meetings. I feel like it gives a fair bit of advantage for native English speakers and I don't think I would be able to participate as effectively any more.

Thanks for raising this concern, @kalev .

I do think that video is superior in these situations, but it is also obviously important that everyone has the opportunity to participate. This is a timely reminder that it's not just the technology that's important, but how we use it.

There are things that a meeting chair can and should do to ensure that everyone has an opportunity to participate. This can include calling out people to get their views, if they've been quiet, or if the topic is relevant to their areas of expertise. Another effective solution is to go round the room to get a sounding on where people are on a question or topic.

Another thing we can do is combine text and video, either having text chat happen at the same time as video, or having preparatory discussions on our issue tracker.

Much of this will be up to whoever becomes chair, but we could certainly document it as good practice and ask volunteers to bear it in mind.

IRC meetings are also much more inclusive where the rest of the community can hang out in the meeting channel and see what's going on and maybe drop a comment if they are interested in a particular topic. Often we've had comments from e.g. mattdm and sgallagh etc during IRC discussions.

My feeling is that concise minutes or meeting notes, circulated to a mailing list after the meeting, are more effective for this. it means we reach a wider audience, and the log is easier to skim.

Issues I see with IRC:

  • It's impossible to tell who is paying attention and, often, people don't pay attention.
  • It's impossible to tell whether silence means consent or objection.
  • You often spend a long time waiting for someone to reply to a question. Conversations are painfully slow.
  • It's harder to keep everyone on topic.
  • Since bandwidth is low, conversations tend to have limited information supplied with them. This makes it hard to participate if you're not already familiar with the issues under discussion. It also makes it easy to make mistakes, since people are working off their own information and assumptions, rather than a shared pool of knowledge.
  • In general, text-based chat is very poor when it comes to resolving differences of opinion or reaching consensus.

I would personally characterise IRC meetings as less efficient and lower quality than those which use video or happen face-to-face.

I would reorganize aday's proposals a bit. The secretary and vice-secretary positions only make sense if we move to BlueJeans meetings, so I would move those roles from Proposal 1 into Proposal 2.

With that change, Proposal 1 would make sense to me regardless of whether we adopt the other proposals. We would still have rotating chairs, but the rotation would be six months rather than weekly. That way we are less likely to forget about duties like updating pagure issues, sending minutes to the list, or using liberally using meetbot commands to take notes. All these are tasks that a six-month chair would get used to doing pretty quickly, and they're low-effort so not a big responsibility commitment. We'd also be less likely to find we don't have a chair on meeting day.

For Proposal 2, I see many advantages and disadvantages, mostly mentioned in this thread already. I'm sure we can move a lot quicker in BlueJeans meetings than we can on IRC, but at the cost of significantly increased workload (for whatever poor soul serves as secretary) and increased effort of attending the meeting. Also makes it much harder for the community to participate. But we could always try it out for one week and see how we like it, Kalev can see how hard it is for him, etc. (I think Kalev's English is very good, but people do tend to talk quickly in voice meetings.) There's really little harm in giving it a try to see how it goes.

Then for Proposal 3, I haven't used https://teams.fedoraproject.org before so no strong opinion here. I'll note we already have an (obsolete, not-updated) Kanban set up by Jiri at https://gitlab.gnome.org/Community/Fedora/workstation-tasklist/-/boards, though it tracks development tasks rather than policy tasks. I'm not a fan of Pagure, but our needs are pretty simple and I'm not sure a Kanban would be a huge benefit. Wherever we track issues, I think it's more important to make sure the list of open issues is small and manageable. Right now we have 23 open issues, which is fine and easy to keep track of without project management tools. Kanbans become important when the number of issues grows larger, and I very much hope the WG doesn't allow that to happen. After all, this is primarily a policymaking group, not an engineering group.

I would reorganize aday's proposals a bit. The secretary and vice-secretary positions only make sense if we move to BlueJeans meetings, so I would move those roles from Proposal 1 into Proposal 2.

Makes sense!

...

For Proposal 2, I see many advantages and disadvantages, mostly mentioned in this thread already. I'm sure we can move a lot quicker in BlueJeans meetings than we can on IRC, but at the cost of significantly increased workload (for whatever poor soul serves as secretary)

I don't particularly see minute-taking as being all that difficult, and depending on how things work out I could potentially help with secretarial duties.

Using an online tool to write minutes (like Etherpad) helps since people can help out and fill missing pieces of information.

... Also makes it much harder for the community to participate.

I'd argue that brief minutes sent to a mailing list are easier to engage with than a noisy IRC channel.

But we could always try it out for one week and see how we like it, Kalev can see how hard it is for him, etc. (I think Kalev's English is very good, but people do tend to talk quickly in voice meetings.) There's really little harm in giving it a try to see how it goes.

I trial seems like a good idea, but I'd probably want to do it for 3 or 4 weeks, to work out any issues.

Then for Proposal 3, I haven't used https://teams.fedoraproject.org before so no strong opinion here. I'll note we already have an (obsolete, not-updated) Kanban set up by Jiri at https://gitlab.gnome.org/Community/Fedora/workstation-tasklist/-/boards,

I'm not going to lie - Taiga isn't all that fantastic and is fairly bare bones. It's nowhere near as feature-complete as Gitlab.

For me the Kanban is important because it would allow us to prioritise more intensively, and maybe try and focus on 4 or 5 key issues at any one time. I think that this would allow the group to focus on getting stuff done.

We can also use the board to track issues in relation to each release, which I think could also help us focus.

For me, where both Pagure and Taiga both fall down is discussion. Issues with lots of comments become unreadable pretty quickly. Gitlab does better here because it has threads and the writing experience is better.

I feel a bit weird about using an upstream platform for Fedora, particularly when the WG plays a strategy and leadership role.

...

After all, this is primarily a policymaking group, not an engineering group.

Many of our policies have an engineering component though...

Then for Proposal 3, I haven't used https://teams.fedoraproject.org before so no strong opinion here. I'll note we already have an (obsolete, not-updated) Kanban set up by Jiri at https://gitlab.gnome.org/Community/Fedora/workstation-tasklist/-/boards,

I just saw that IoT is using Taiga, as are a bunch of other Fedora teams: https://teams.fedoraproject.org/discover/search?order_by=-total_activity_last_month

Being in the same place as these other teams could be nice.

Login to comment on this ticket.

Metadata