Thanks for this, @tpopela! Other possibilities:

• Organise test days
• Change proposals:
  • Call/reminder/review for workstation change proposals
  • Review workstation change proposals, to see what needs to be done on our side

One of the things I'm thinking of here is the issues we had around power profiles - in one case we approved a change but then didn't action it to include the package. Then later (too late), we realised that there should have been a change proposal when one hadn't been made.

Another one: update the screenshot(s) on the website.

• Organise test days

Yes,the test days - we won't get into the situation again, when we will find out that the test day is just few days away. When it should take place? Once we have the GNOME XX Beta packages in? Who should own this step? Could it be @sumantrom from the QE side together with someone from WG (could it be @kalev as he had always played an active role there).

• Change proposals:
• Call/reminder/review for workstation change proposals

Shouldn't we just follow the general Fedora policy there instead of inventing our own? What's your thinking there?

• Review workstation change proposals, to see what needs to be done on our side

You mean changes that were not proposed by any of our members (if it would be done by our members, then we would have the issue created in our tracker and hence would be covered by "Enable new features / include new packages" task/item that I've mentioned in the description.

One of the things I'm thinking of here is the issues we had around power profiles - in one case we approved a change but then didn't action it to include the package. Then later (too late), we realised that there should have been a change proposal when one hadn't been made.

Wasn't it a problem with not marking the issue with pending-action label and then not following up properly in the following meetings? Should we as part of the "status updates" part of the meeting actually go through all the issues that currently have the pending-action label and ask explicitly for the status?

• Organise test days

When it should take place? Once we have the GNOME XX Beta packages in?

Yes, I think that's when we've done it recently.

Who should own this step? Could it be @sumantrom from the QE side together with someone from WG (could it be @kalev as he had always played an active role there).

@kalev has been doing a great job here indeed. It's good to have someone on the WG take ownership of this, even if it's just to keep an eye on things.

• Change proposals:
• Call/reminder/review for workstation change proposals

Shouldn't we just follow the general Fedora policy there instead of inventing our own? What's your thinking there?

Right, I agree that we should follow the Fedora schedule for this, and we should follow the dates provided. My thinking for this item is to make sure that change proposals are made in good time for all the workstation changes we have planned, or that other contributors have planned.

So an action might be, 2 weeks before the change proposal deadline, we review our tickets for the current release, to check which of them might need a change proposal, and possibly send out a mail to fedora-desktop to encourage workstation contributors to make their own change proposals if needed.

For me this is part of the working group's role of making sure that our edition follows Fedora processes.

• Review workstation change proposals, to see what needs to be done on our side

You mean changes that were not proposed by any of our members (if it would be done by our members, then we would have the issue created in our tracker and hence would be covered by "Enable new features / include new packages" task/item that I've mentioned in the description.

Yes, maybe the "enable new features" task is sufficient here. My motivation was to make sure that we don't miss any changes that should have been made during the cycle. Ideally this would happen towards the end of the change process but in time to implement changes for beta.

It might be appropriate to have a checkpoint 1 week before the change 100% code complete deadline, though I don't want to overload the schedule...

(Side note: personally I'm still not really in favour of pushing to enable features early. I think that they should be enabled when ready.)

One of the things I'm thinking of here is the issues we had around power profiles - in one case we approved a change but then didn't action it to include the package. Then later (too late), we realised that there should have been a change proposal when one hadn't been made.

Wasn't it a problem with not marking the issue with pending-action label and then not following up properly in the following meetings? Should we as part of the "status updates" part of the meeting actually go through all the issues that currently have the pending-action label and ask explicitly for the status?

Yes, that was one of the issues, and I agree that effective issue tracking is the solution there. But I think that there was a separate issue with the change proposal being missed (see the thread).

• Review workstation change proposals, to see what needs to be done on our side

You mean changes that were not proposed by any of our members (if it would be done by our members, then we would have the issue created in our tracker and hence would be covered by "Enable new features / include new packages" task/item that I've mentioned in the description.

Yes, maybe the "enable new features" task is sufficient here. My motivation was to make sure that we don't miss any changes that should have been made during the cycle. Ideally this would happen towards the end of the change process but in time to implement changes for beta.

It might be appropriate to have a checkpoint 1 week before the change 100% code complete deadline, though I don't want to overload the schedule...

(Side note: personally I'm still not really in favour of pushing to enable features early. I think that they should be enabled when ready.)

In principle, I agree we want to only enable things when they're ready. But in my experience, features are rarely ready right when we enable them. I'd prefer to have a bias for action to ship things in Rawhide and use that as a forcing function to make sure stuff we want to ship provides the experience we want. That also gives us the maximum amount of time to iterate on features, as we get all that extra time leading up to the beta freeze to get things in shape.

The approach followed with the KDE Spin is that we lay as much groundwork for new features ahead of time as possible. For example, I shipped Wayland by default for Plasma in October 2020 and spent the entire time following that on fixing bugs on Plasma Wayland leading up to the Fedora Linux 34 release. For Fedora Linux 35, I modified the power-profiles-daemon enablement to be global instead of Workstation specific because KDE Plasma 5.23 will ship support for it, and that will be a post-GA update for F35.

This is obviously more difficult for Workstation, especially with things that require design work, as we're pretty much locked into the GNOME development cycle process. But if we know what we want to do, we can at least start doing the engagement for that right now and work through implementing various fallback strategies so that we can achieve our targets. Items like #246 require us to do some testing of the fallback strategy (shipping the extension) on the various GNOME experiences (modern shell, Classic shell, Flashback shell) as well as engaging with GNOME Shell upstream about integrating the functionality directly in.

What I'm worried about is that we forget to do anything at all, and things continue to slip through our fingers. I don't want a repeat of the power-profiles-daemon issue (#191) or the malcontent issue (#186).

In principle, I agree we want to only enable things when they're ready. But in my experience, features are rarely ready right when we enable them.

I wasn't intending to reopen this discussion - we had it once, don't really want to going over the same ground again. But since you've made your case - my issue with enabling new features early is that it forces me to chase the feature to improve its UX, and if I don't, then we automatically end up with product quality being degraded. That's not a nice position to be in personally, and it's unreliable.

What I'm worried about is that we forget to do anything at all, and things continue to slip through our fingers.

That's just a matter of having effective issue tracking. Pushing packages into a release doesn't seem like a good substitute for that.

Maybe add "packageset review and image size check" to the list? Traditionally we do it during GNOME test week, but I missed it this time around due to travel related distractions.

@adamwill are you aware of anything else that would be good to be tracked in the Workstation release checklist? You ceased many fires so your experience is valuable here :)..

nothing off the top of my head, you already covered updating appstream metadata I think?

@adamwill would it be things that were done in https://pagure.io/fedora-workstation/issue/245 ?

yes.

Draft schedule for F36 workstation:

2021-11-03 - release planning

• Call for workstation changes/plans

2021-12-14 (2 weeks prior to system wide change proposal deadline) - change proposal check

• Check if we're missing any change proposals

2021-01-04 (2 weeks prior to self-contained change proposal deadline) - change proposal check

• Check if we're missing any change proposals

2021-01-18 (self-contained change proposal deadline) - Enable new features / include new packages

• Review change proposals
• Add or enable any features that are planned

2022-02-08 (branch from rawhide) - Post-branch tasks

• Plan GNOME test day (to happen when GNOME beta is ready)

2022-03-01 (2 weeks prior to beta) - Prepare beta release

• Generate GNOME Software previews
• Disable any new features as necessary
• Package set review and image size check

2022-03-15 (beta release) - Post-beta tasks

• Start planning release marketing ("what's new in F36" post)
• Add upgrade artwork to gnome-software

2022-04-19 - Release day

• Update website screenshot

Did someone say "schedule"? I'd be happy to add the above to a Workstation schedule on the overall F36 schedule (with the same milestones for subsequent releases), if that would be helpful to the WG.

Did someone say "schedule"? I'd be happy to add the above to a Workstation schedule on the overall F36 schedule (with the same milestones for subsequent releases), if that would be helpful to the WG.

That'd be great, thanks!

Done: https://fedorapeople.org/groups/schedule/f-36/f-36-workstation-tasks.html

I've tried to import that calendar (through the ICS file) into Google Calendar and after several tried it actually worked, but then I saw that there are two "long term" events created one for our "schedule" aka starting at Tue 2021-11-02 and ending on Tue 2022-04-19 and the other one probably for the whole Fedora 36 cycle. @bcotton is it possible to not include these or one should rather import the things from the ICS file to his own calendar and remove these long term events?

@tpopela maybe. The tool that generates the files has an option to only show milestones, which removes those two "container" tasks. But some teams legitimately use container tasks on their schedules, so making that change would break them. I don't see a way to remove those particular entries, unfortunately. I'm not sure why the tool inserts them into the json and ics files but not the HTML.

Related, I didn't add the "workstation" flag to the freezes, so they don't appear on the calendar. Would you like me to add those?

I've pushed a template for the schedule to our docs: https://pagure.io/fedora-workstation/workstation-docs/pull-request/3

With that, I'll call this done, unless anyone can think of anything else we need to do.

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/workstation/tickets/issues/250

Please continue any further discussion there.