Create a new schedule that complements the release schedule, but instead focuses on community/outreach activities like Test Days, easyfix triaging, etc.
There is a lot happening in Fedora all the time. This is one reason why having a schedule is so helpful, so that multiple stakeholders can keep up independently on key activities that need to happen by a certain date. We have a great example of this for the actual production of our Linux distribution releases, but there is no parallel in the community and outreach end of things.
In fedora-join/Fedora-Join#286, there was an idea of adding an "easyfix day" and adding that into the release schedule. The motive to add it there is because that is an established schedule that people in the project pay attention to. The feedback on why not to do it is that the release schedule is hyper-fixated on key activities related to the production of the distribution itself. Adding things to that schedule that are not absolutely required to making a distro makes it harder for folks to keep up with the major milestones that mean we might ship late.
But there is a need that remains unaddressed for highlighting important community and outreach steps that are loosely tied to the six-month cadences we are used to for Fedora. How do we best capture those activities and make them visible to more people?
This ticket proposes the creation of a community/outreach schedule, that also fits into the six-month cadence we are used to but remains separate from the existing release schedule. I am opening this as a Council ticket to start because some help is needed from a centralized place to get this idea going, and later it could sit somewhere separate from the Council. As the Council, we can give shape and form to this idea before it goes out into the community for implementation.
This has always been a major missing for QA. QA relies on Community feedback the most and hence reaches out ideally in every way possible. We understood that new contributors don't understand release cadence (ie release cycle, beta/final phase) very well. To counter the problem, QA team devised it's dashboard. The QA dashboard helps a contributor understand what is happening and where they can find relevant pathways to explore. It was first built in 2019 and we keep adding small features as an when required. The dashboard can be found here https://qa.fedoraproject.org/
+1
We'd also briefly discussed a system similar to change proposals, but for community related proposals (see https://pagure.io/mindshare/issue/197 ). The goal was pretty similar---increase visibility of all the community tasks that are done per release cycle. I think this, a community schedule, will work better and will subsume the idea of the "community change proposals".
See my rationale here https://discussion.fedoraproject.org/t/fedora-council-tickets-ticket-482-devising-a-community-schedule-to-complement-the-release-schedule/105785/2.
Metadata Update from @amoloney: - Issue priority set to: Next Meeting (was: Needs Review)
Mindshare teams have a better vehicle for getting repeated tasks during release cycles into a calendar that anyone in the community can see and follow.
If they're actually release cycle tasks, they should be in the existing release schedule. That's why, for example, Design and Magazine have tasks on the schedule.
But the EasyFix days task (as an example) isn't associated with the release, so it shouldn't go in. But I'm not sure there's a need for anything grand here. To channel my inner Matthew Miller for a moment, this is a problem that Discourse's calendar functionality could solve pretty easily.
Metadata Update from @amoloney: - Issue priority set to: Needs Review (was: Fast Track) - Issue tagged with: Next Meeting
Im going to look into this a little more as there are a few events that happen around the project that would benefit from being on some kind of findable schedule of calendar. Im also thinking of moving the Elections to this new setup, if a suitable one is found, as this is not release-blocking, but related to the release schedule and would fit better in a more community-facing calendar of events.
Metadata Update from @amoloney: - Issue untagged with: Next Meeting - Issue assigned to amoloney - Issue priority set to: None (was: 3) - Issue tagged with: elections, events
Im also thinking of moving the Elections to this new setup, if a suitable one is found, as this is not release-blocking, but related to the release schedule and would fit better in a more community-facing calendar of events.
The fact that it's tied to the release date makes it a better fit for the current system, since you automatically get changes to the election schedule if the release date moves. That said, the resulting output could be pulled by something else in order to render it in a new place.
Good point about the automatic Election date changes - something I will need to consider how to keep in sync when mocking up an 'alternate' schedule (dont know what we would call it yet)
Log in to comment on this ticket.