#218 The Workstation Working Group is a bottleneck
Opened 6 months ago by aday. Modified 3 months ago

A personal anecdote: before I joined the Workstation WG, I tended not to have many Workstation-specific design tasks on my work list. Since I joined, I have a persistently high number of Workstation design tasks to do. During that time, the number of design tasks that needed doing has not really changed, nor have I seen design tasks being assigned to anyone else.

That anecdote seems indicative of more general tendencies within the group. Action items tend to be assigned to WG members rather than non-members. Non-members are less likely to get involved in Workstation initiatives.

Reasons why this happens, in my opinion:

  1. The workstation working group is part governing body (with voting rules and so on), part management team, and part, well, working group. The group needs to be small to fulfil its governance and management roles, but this limits the number of people doing the work.
  2. There isn't a strong sense of who is willing and able to do workstation tasks. (We sometimes rely on the internal Red Hat management chain for this, but that's only partially represented on the working group.)
  3. There's no clear way for people to volunteer to work on Workstation initiatives, other than the ambiguous practice of turning up to WG meetings as a non-member.

Some potential, not fully thought through solutions to this:

  • Create sub-teams of the working group, to whom tasks can be assigned
  • Grow the working group, with a combination of voting and non-voting membership (perhaps even reduce the number of voting positions)
  • Make all Red Hat Desktop Team managers working group members
  • Establish some kind of protocol for when we assign tasks, to avoid hoarding within the group (eg. instead of asking for volunteers, identify a list of people who could complete the task, and then assign someone to approach them)

@mattdm it'd be interesting to get your perspective here.


I'm definitely open to a restructure. The initial WG design was simply because we (in particular @mjg59, who was on the board at the time) wanted to make sure that the people doing the work were also the people making decisions.

In general with volunteer work, assigning things doesn't work nearly as well as available people pulling work. it sounds like the situation we're in here is that there are people who may be interested in helping but we don't know who they are or what they're available for — and they don't feel empowered to take tasks.

I don't think we should automatically make all Red Hat Desktop Team managers voting members, because that seems unbalanced in decision making (rather than providing different perspectives). But maybe there is a different way to increase that involvement.

It might be time to move beyond the "Working Group" nomenclature — at a Fedora Council meeting a few years ago we agreed we didn't really need to require that. We just want to make sure each Edition has a definite formal structure and some active body with explicit membership rules and voting policies. The previous widely-used term "SIG" often applies in Fedora to groups that are merely expression of interest in a topic.

Perhaps "Team" would be a better approach, and if there are more members of the team than can make decisions effectively, a Steering Committee within that team?

I like your suggestion for task assignment protocol. That fits with the idea of having sub-teams of people who have expressed interest in specific areas.

Metadata Update from @aday:
- Issue tagged with: meeting-request

6 months ago

Does March 23 sound OK for this? I will avoid scheduling anything else on the same day that we discuss this, because this topic will probably take the whole time.

Does March 23 sound OK for this? I will avoid scheduling anything else on the same day that we discuss this, because this topic will probably take the whole time.

No rush from my perspective.

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

6 months ago

We had a good discussion about this at today's meeting. We produced some potential actions but nothing in the way of a concrete plan, and more discussion is probably needed.

Some of the key points from my perspective:

If the WG has tasks that need to be assigned internally in the Desktop Team, @tpopela can do that as product owner. However, if we want to do this, we need to be looking ahead. He's not in a position to assign tasks at short notice.

Other actions we discussed:

  • Making the meetings more approachable, and doing more community building around the WG meetings.
  • Putting out public calls for help for particular tasks, when we have them.
  • Ensuring that our tickets have assignees.

@otaylor asked whether we really have an excess of tasks that are appropriate for additional contributors. In response, @ngompa and @langdon argued that we currently tailor our task list to the resources that we have available - that there's more work that could be done, if there were more volunteers.

Personally I can see both sides of this argument. Something I've realised is that, in my work on the WG, I bring my own personal specialism - so being on the WG as a designer, I tend to generate design tasks as well as resolve them. This makes me wonder about the extent to which we should seek to have a range of specific specialisms involved. What would a WG look like with marketing and QA involved, for example?

There were a few different takes on the role of the WG meetings. I made the point that we ought to try and grow contributions outside of the meetings (through the mailing list, IRC, Pagure, etc). @langdon countered that meetings are an effective way to build volunteer teams. Personally I can see that logic, but I'm also uncertain to what extent we can grow the current meetings without undermining their effectiveness. We currently have 10 members plus guests - that's already bumping up against the limits of meaningful participation.

Suggested next steps:

  • Come up with a list of tasks that we might want additional contributors to work on (either existing tasks or hypothetical new ones).
  • More discussion, with a view to developing a specific plan.

One other thought that occurs to me: if we are going to look to get more contributors, then we probably need to think about the WG's place in the community. Currently we're mailing list and IRC-based. The IRC channel is generally dead. We don't do much interfacing with discussion.fedoraproject.org. Discourse doesn't even have its own workstation area (it has "desktop", which covers all desktops and desktop spins). All things to think about...

Potential additional work items

A running list of potential additional tasks we might do, if we had more volunteers. Feel free to edit and add!

  • Active maintenance of our own app selection metadata, to be featured in GNOME Software
  • Regular marketing and outreach activity
    • Articles for Fedora Magazine
    • Posts for social media
    • Community engagement through discourse etc
  • Something around DX? Planning, writing documentation
  • More workstation-specific desktop design work
    • Sadly we often seem to be blocked on development resources, but ideally we'd have active design work around Anaconda, ABRT, etc
  • More developers doing Fedora desktop integration work, eg:
    • Plumbing 3rd party repos into gnome-initial-setup and gnome-software
    • Live session integration
  • More in the way of workstation<->QA
    • Updating desktop test plans
    • Reports and updates based on test days, retrace server, etc
  • More activity around app availability:
    • We're currently stuck with #108 - presumably some of this work could be shared
    • People to monitor app usage, bring interesting apps to the working group, spot packaging issues
    • Volunteer help with Fedora Flatpaks
  • Sub-groups to investigate particular technical questions/challenges, like disk encryption, memory usage
  • Data gathering, either through automatic reporting or research exercises

@aday I really like where you are going with this. The original intention was definitely intended to be a cross-functional team. I love the ideas for more community involvement.

On Discourse in specific: I'm happy to create a Workstation category. I'm trying to make those when requested rather than doing a Field of Dreams thing. :)

Something I've realised is that, in my work on the WG, I bring my own personal specialism - so being on the WG as a designer, I tend to generate design tasks as well as resolve them. This makes me wonder about the extent to which we should seek to have a range of specific specialisms involved.

An example: while working on #220 yesterday, I noticed that the last time the workstation web page was updated was 2 years ago, by @ryanlerch , when he was on the WG. Which makes you wonder: is our approach to our web presence to wait until a designer independently comes along, joins the WG, and does the work? Or should we consider these tasks as part of the WG's responsibilities, and recruit accordingly?

A straw man proposal:

  • Change the name of the group. Workstation Steering Group?
  • Go through our issue tracker, make sure that every issue is assigned
  • Async communications
    • Move from fedora-desktop mailing list to Discourse
    • Create a Workstation category on Discourse
  • Improve the IRC situation
    • Retire #fedora-desktop
    • Advertise #fedora-workstation more widely
  • Identify help-wanted tickets in the issue tracker, publicise them on Discourse
  • Raise the visibility of the workstation group - it's invisible if you go through the usual "how do I contribute to Fedora?" pages. We probably just need to go through and insert ourselves into those.
  • At some point each cycle, identify long-term initiatives that we want to feed into the Red Hat planning process
  • Address diversity of responsibility and expertise within the group:
    • Update our list of responsibilities on the wiki (to include QA, marketing and UX activities).
    • Either:
      • Outline some of the specialisms we want in the group, and aim to fill them as best we can.
      • Create a set of "lead" positions (for QA, marketing, UX, etc) which we want to fill. Leads wouldn't need to be voting group members.
    • Set up a workstation volunteers network - advertise the type of tasks we want filling, invite volunteers to introduce themselves, participate in our channels and so on

I support this straw proposal, although I also even more support the idea that y'alls self-determination for the best course here is more important than my opinion. :)

A few notes:
I can set up the Discourse category right now if you want, but I want commitment from at least a couple of people to actively participate so it doesn't die on the vine.
IRC: the move to Matrix is coming as soon as we get the RH internal financing sorted out. I think we're going to want to revisit Fedora channels in general at that point.
The "how do I contribute" pages need work in general. https://whatcanidoforfedora.org/ is cute but could use a major update. But let's not let that be a blocker and I support inserting the group into whatever exists now as a first step.
Long term initiative planning is very helpful, because the Council can then take that to CPE and OSPO quarterly planning meetings.

Thank you Allan for putting this together. I generally agree, but few nitpicks follow:

  • Async communications
    -- Move from fedora-desktop mailing list to Discourse
    -- Create a Workstation category on Discourse

Will we have a capacity to be able to create a lively community there? Honestly I do really have problems to keep up with the Silverblue category/forum on Discourse.

  • Improve the IRC situation
    -- Retire #fedora-desktop

I'm curious about this - should we constantly nag people to move to #fedora-workstation? Also is #fedora-desktop something "Fedora official" as it is running on GimpNet and not on FreeNode as other official Fedora channels? So I'm not sure whether we can even retire/close it. Of course it can stay open with some topic set.

  • At some point each cycle, identify long-term initiatives that we want to feed into the Red Hat planning process

Agreed, but as I mentioned in the meeting is has to be something that we have expertise internally in the Red Hat Desktop team (so no filesystems, ..).

Thank you Allan for putting this together. I generally agree, but few nitpicks follow:

  • Async communications
    -- Move from fedora-desktop mailing list to Discourse
    -- Create a Workstation category on Discourse

Will we have a capacity to be able to create a lively community there? Honestly I do really have problems to keep up with the Silverblue category/forum on Discourse.

I think that a workstation category for users would be good in and of itself, in that it will give a clearer way for us to communicate with users, and would give workstation greater presence in the community. So I think that having a workstation category is good for that.

Regarding moving fedora-desktop, my idea here was that, by moving to more modern infra and by being closer to where the community is, we'd have more exposure and increase the possibility of getting new contributors. However, you're right about the noise issue and we probably need a split between user forums and the communications channel for contributors.

Would it make sense to have that on Discourse? You could have Workstation as a top level category and then Teams/Workstation for contributors?

  • Improve the IRC situation
    -- Retire #fedora-desktop

I'm curious about this - should we constantly nag people to move to #fedora-workstation? Also is #fedora-desktop something "Fedora official" as it is running on GimpNet and not on FreeNode as other official Fedora channels? So I'm not sure whether we can even retire/close it. Of course it can stay open with some topic set.

Indeed getting people to migrate is tricky, but I do think that the current split between #fedora-desktop and #fedora-workstation doesn't help us. We'd do better to consolidate our conversations in one place. Maybe the best we can do is make the case for people to migrate to #fedora-workstation.

  • At some point each cycle, identify long-term initiatives that we want to feed into the Red Hat planning process

Agreed, but as I mentioned in the meeting is has to be something that we have expertise internally in the Red Hat Desktop team (so no filesystems, ..).

Yep!

Will we have a capacity to be able to create a lively community there? Honestly I do really have problems to keep up with the Silverblue category/forum on Discourse.

I personally find it easy to keep up by having the app on my phone and treating it like the other social media I follow. (This is nice because you can also have Ask Fedora, GNOME Discourse, etc., right there.)

The forum thing can also become part of a daily workflow — as more Fedora stuff ends up there, it becomes something to check just like you'd check an email folder you've got mailing list messages filtered into.

If you're used to a more email-based workflow, Discourse isn't perfect but is definitely much better than most forums. See https://discussion.fedoraproject.org/t/guide-to-interacting-with-this-site-by-email/25960 for details.

  • Improve the IRC situation
    -- Retire #fedora-desktop

I'm curious about this - should we constantly nag people to move to #fedora-workstation? Also is #fedora-desktop something "Fedora official" as it is running on GimpNet and not on FreeNode as other official Fedora channels? So I'm not sure whether we can even retire/close it. Of course it can stay open with some topic set.

FWIW I'm active in #fedora-desktop but I do not use #fedora-workstation because it is on freenode, which I do not use because polari doesn't handle NickServ very well and creates desktop notifications each time I join the network, which is annoying.

The point is probably not worth discussing too much because our freenode channels will be moving to Matrix soon anyway.

As discussed at today's meeting, I've started filing issues for some of the action items described above:

  • Workstation user and contributor community on discussion.fedoraproject.org - #223
  • Consolidate and advertise Workstation chat channels - #224
  • Documentation issues for Workstation contributors - #225
  • Change the working group name, maybe create an additional group for contributors - #226

This doesn't cover everything, but seems like a decent set of tasks to start with.

I'm retagging this for meeting request to talk about it next week.

Metadata Update from @ngompa:
- Issue untagged with: meeting
- Issue tagged with: meeting-request

4 months ago

About:

  • Improve the IRC situation
  • Retire #fedora-desktop
  • Advertise #fedora-workstation more widely

I mentioned on IRC that:
"we had the choice of being close to fedora by having a channel on freenode, or close to our upstream gnome by having a channel on irc.gnome.org, we chose the latter"

I am not on irc.gnome.org because my ISP regularly gets banned from OFTC.

I am not on irc.gnome.org because my ISP regularly gets banned from OFTC.

irc.gnome.org isn't part of OFTC.

Probably better to discuss IRC on #224.

Metadata Update from @ngompa:
- Issue untagged with: meeting-request
- Issue tagged with: meeting

3 months ago

Metadata Update from @ngompa:
- Issue untagged with: meeting

3 months ago

Login to comment on this ticket.

Metadata