As user/packager, the schedule for Fedora release development available at Fedora Linux 39 Schedule: All (example for F39) is hard to read. I suppose is also a bit hard to maintain, especially when milestone slip.
What about migrating the schedule to something more manageable? From a quick search I’ve found https://www.openproject.org which is also OSS. Things IMO are a pro:
Users can subscribe to the calendar with their own client through iCalendar
Tasks can be assigned, so the user responsible for the task can receive a remainder
Gantt timeline (which IMO provides better view as a user)
Not sure about schedule management when things slip due to NO-GOes, but I suppose it would also provide better interface for who is responsible for updating the timeline.
Up until now, that schedule has been generated by the Fedora Program Manager, using some scripts to convert an internal Red Hat system to html (and I think also an xml and json export). I complained about this too, and Ben Cotton took that as #action bcotton to make it a little prettier, but changing the whole system would have been a lot of work, and… there are a million things of high importance.
Wellllll. Fast forward to now. We no longer have a paid Program Manager position. The soon-to-be-real Operations Architect role won’t be the same thing exactly — and in particular, won’t be connected with that program management office or really tied to that RH-internal software.
So, we could definitely make some changes — although I’m not sure it will be a first priority, it’s something to consider.
I know it used to all be generated using TaskJuggler a long time ago. (The Fedora 20 release schedule is still included in the TaskJuggler sources as an example). So, if it’s a question of generating the release schedule, I can help with that and put it up in a pagure repo or something so it can be maintained collectively by the community and not by an individual? I’ve got taskjuggler packaged in a copr. I know the css etc. there can be modified too—not sure how much, but could look.
I agree we’d need something better, but in my view it’s not just about making it “prettier”; what I’d want is webcal links that provide meaningful simple output for the general public, too. And if you have that to begin with, then you can just use one of the gazillion web calendar UIs out there to also display it on a website from the webcal/ics instead of the other way around.
I expressed this wish in some chat discussions before, and more recently in this social post (and this follow-up comment specifically about how Fedora’s release calendar is not currently serving that need well).
I’m looking at this from a public relations and end-users marketing standpoint.
If you want to have your excruciatingly detailed internal engineering meetings calendar out there that’s cool, but casual community members would benefit from also primarily having something much simpler that they can mix with their daily lives’ calendars.
I know that TJ can create whatever ical exports one wishes, it’s quite easy. I also think the system Ben used has this feature—there’s a link to export the ics/json at the bottom. So it’s just a question of setting up the export with the data that folks feel is useful for public consumption.
If there’s a way to automatically import this into fedocal, that’ll be nice. If it needs to be done manually, I don’t think it’s worth it.
The “all” schedule is a bit much for most purposes. That’s why there are various focused versions for different groups and purposes. The “key” view is the most useful for a general audience, probably - Fedora Linux 39 Schedule: Key . The other views are all linked, just above the column titles. Each view has ics and json exports available linked at the bottom.
Something better would be fine, but there are always hurdles, of course. If we wanted to self-host OpenProject, someone would need to find and justify the resources to deploy it and maintain it. If we wanted to pay for it as a service, there’s a bunch of RH hoops to jump through which I think @mattdm knows all about…
Honestly, for this purpose, some terribly old-school app you could just run on a regular computer would be easiest.
Yeah, it’s pretty intense. I’ll fight for it for open source services that really make sense for us — but let’s make sure it’s something we need to prioritize first.
I can see some problems with the current workflow:
“The schedule lives in Smartsheet (only available to Red Hat employees)” - that assumption is self explanatory.
At every update there should be manual processing of exporting the XML and run through the Fedora script.
The .ics and .json export are fine, but consumers need to know from somewhere else an update has happened and manually update their local calendars.
There’s no way to assign tasks and have the assignee receive reminders (I know the last release flow was weird due to the sudden drop of the Program Manager, but if we had a way to assign tasks we could have avoid slipping/forgetting tasks)
The last two are those that made me file this proposal. I’ll leave further considerations to you on budget/resources priorities.
Matthew, do you happen to know why we switched from TaskJuggler to Smartsheet in the first place? Was it just about integrating with RH PM’s way of doing things? If so, does the change to an “operations architect” give us flexibility to maybe…change back?
Yes, I believe that integration was the reason. I remember some dissatisfaction with Taskjuggler, too, although I’m hazy on what that was about. Most importantly, yes, absolutely on the flexibility to change.