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:
Some potential, not fully thought through solutions to this:
@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
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
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:
@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:
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...
A running list of potential additional tasks we might do, if we had more volunteers. Feel free to edit and add!
@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. :)
Meeting minutes. https://meetbot.fedoraproject.org/teams/workstation/workstation.2021-03-24-02.15.log.html
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:
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!
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.
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:
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
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.
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
Metadata Update from @ngompa: - Issue untagged with: meeting
It would be nice to close this issue. Maybe if we can have a conversation about anything else we can do to delegate and onboard more effectively, first...
We discussed this at yesterday's working group meeting. The consensus seemed to be to focus on #223 and #224, which can we track separately.
I think we do have a shared desire to expand the contributor base and get more people involved, so no doubt we will come back to this topic one way or another.
Metadata Update from @aday: - Issue close_status updated to: Won't fix - Issue status updated to: Closed (was: Open)
Metadata Update from @catanzaro: - Issue untagged with: meeting-request
Log in to comment on this ticket.