#71 WIP: Require rejected proposals to be resubmitted
Closed a year ago by zbyszek. Opened a year ago by bcotton.

@@ -63,6 +63,9 @@ 

  Tagging the issue for the meeting agenda is understood to disqualify the proposal for fast-track status.

  Proposals that receive a unanimous vote are immediately considered approved or rejected as appropriate, independent of fast-track status.

  

+ Proposals that are rejected may be submitted by reconsideration, but they must go through whatever process was originally required before FESCo begins voting.

+ For example, this means a rejected Change proposal must be resubmitted to the Change Wrangler as outlined in the xref:program_management::changes_policy.adoc[Changes process].

+ 

  == Meetings

  

  FESCo meets usually on a weekly basis, check the link:https://fedoraproject.org/wiki/FESCo_meeting_process[FESCo meeting process]. You should verify the meeting date and time from the link:https://admin.fedoraproject.org/mailman/listinfo/devel[devel] mail "_Plan for tomorrow's FESCo meeting_" being sent in advance.

Process note: I am opening this for comment before creating an associated ticket in order to get feedback from the community first.

Explicitly require that any rejected proposal has to go through the
process it originally required.

I intentionally left this vague in order to account for things apart
from Change proposals, even though that's what highlighted the need for
this policy change/clarification.

Strong -1. We already follow a procedure where significantly modified proposal are resubmitted for discussion on fedora-devel and we give people time to comment and wait until the discussion has died down again. This proposal would make the process even more onerous, by requiring the process to be restarted to go via the FPM again. Requiring this even for trivially-updated proposals is not useful. It's not like the extra discussion is going to bring new information. Even for significantly-changed proposals there's always much less comments in the second round. If we resubmitted an unchanged proposal for discussion again, we wouldn't get anything, except possibly a repeat of the same arguments.

Then there's a technical consideration about how voting works: a proposal must reach absolute majority to be accepted. But during meetings we are often very close to quorum. And people who abstain are effectively against, because 0 and -1 both subtract from the required majority. So getting a proposal accepted is more about having enough participants vote at all than about having support. During a typical meeting, one or two people abstaining is enough to prevent a proposal from being accepted, even if majority of FESCo members would in general support it. Allowing a quick revote if there's clear support from folks who missed a meeting is a way to fix those cases.

Pull-Request has been closed by zbyszek

a year ago
Metadata