That sounds pretty reasonable to me. It would be good for them to be polled as well so they don't have to remember on their own to do this. For example, if they must respond by one week before branching, perhaps a notification should be sent three weeks before branching (arbitrary, feel free to season to taste) to ask for a response. It might be nice to use Bugzilla for such notification since it has the ability to remind people of needinfo status.

An alternative thought that perhaps has already been considered: I haven't maintained a spin myself before - would a spin maintainer typically perform some trackable activities during each release, such as making commits in a repo for it, or taking actions in Bugzilla? If so, perhaps we could use that as a signal of "I am here and working towards the release"?

I'm opposed to sending a reminder. It sounds like a very nice thing to do, but it also encourages people to not pay attention and do as minimal maintenance as possible on their Spin. If the hurdle is already low enough that they have to send an email, sending them a reminder to jump that hurdle kind of defeats the purpose.

If we had data, in an automated and collected manner, that could be easily queried for activity without knowing all of the various items that go into a Spin and how to get the data out of the tools, that would be cool. I'm thinking like a simple dashboard page. We don't have anything like that to my knowledge.

OTOH, people are likely to forget that they need to send the mail, even if they are otherwise active. Then we'd be like "OK, this spin seems active, but there was not mail, are we going to drop it... no let's send out an quick reminder.". So let's just cut this short and send a reminder up front. If people want to game the system, they'll find a way anyway.

At a basic level, spin activity is essentially maintaining the kickstart file and making sure it still works. This could mean that there's little visible activity for several releases in a row. By sending an email reminder that the maintainer has to reply to, they're at least indicating they're still there to look at any issues that may arise.

Consider as an example the F29 spins list. I emailed all spins owners with a message of "please reply to this email or update the date on the wiki page if you've reviewed the information and everything is correct." Even with a follow-up email, less than half have done this. So even with a low bar, many spins won't clear it.

So, for a few cycles a while back releng asked spin/lab owners to sign off before beta and before final on their spin that at least one person tested it. If the spin/lab wasn't signed off on, it would be dropped. We did not ship a few things that first time, but a few releases later everyone was busy and we stopped tracking this. (see the Beta and Final cols in the Releases/N/Spins page where this was done).

There were a few issues with this process, mostly that the testing window was variable (you wanted to test when we were making "RC"s but before we were "GO" for the release) and then it also needed coordination with websites (if we were not shipping X, they needed to know asap so they could adjust pages).

I'm definitely in favor of some process here, espeically if the FPM will track things and keep the various groups updated. Perhaps a email at the start of the cycle, but I think it would be nice to have testing during the cycle as well. We definitely have had spins/labs that composed, but failed to function in various ways.

It sounds like sending the e-mail reminder is OK, because even with that people don't reply.

Spins and Labs must send a request for being built in the next release (from a human) to the Program Manager as part of the release calendar or they will be dropped for that release.

PROPOSAL: In each release cycle, the Program Manager will send an request to the owners of all Spins and Labs to confirm that they should be built for the next release. The ones that don't respond will be dropped for that release.

PROPOSAL: In each release cycle, the Program Manager will send an request to the owners of all Spins and Labs to confirm that they should be built for the next release. The ones that don't respond will be dropped for that release.

I think this should happen before branching, as suggested in the original post, with the deadline happening 7 days prior to the Branch (so RCM has time to update pungi config).

With that addendum, I'm +1.

I omitted any details about the timing or the communication method and the response format on purpose. I think we can leave that to the PM to specify / adjust those details as we process is used.

I can meet you in the middle with:

"In each release cycle, the Program Manager will send an request to the owners of all Spins and Labs to confirm that they should be built for the next release. The ones that don't respond will be dropped for that release. Responses to this request must be made sufficiently in advance of the Branch to allow RCM to react to the results."

+1 to the amended proposal

On 09/04/2018 10:02 AM, Stephen Gallagher wrote:

"In each release cycle, the Program Manager will send an request to the=
owners of all Spins and Labs to confirm that they should be built for th=
e next release. The ones that don't respond will be dropped for that rele=
ase. Responses to this request must be made sufficiently in advance of th=
e Branch to allow RCM to react to the results."

+1

I can meet you in the middle with:
"In each release cycle, the Program Manager will send an request to the owners of all Spins and Labs to confirm that they should be built for the next release. The ones that don't respond will be dropped for that release. Responses to this request must be made sufficiently in advance of the Branch to allow RCM to react to the results."

+1

+1 to the amended (middle) proposal.

It's been a week and I see +5 votes. I'm marking this as accepted, and since I'm sending out an announcement email about accepted changes anyway, I'll include this too.

Announced in https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/3QOBBMSOQDMK4ILIPMAO5EVERNZDTMWQ/.