#1921 Clarification on the new ticket policy
Closed: Accepted 4 years ago Opened 4 years ago by sgallagh.

Since we established the new ticket policy, I've gotten a few questions about how it will work, so I want to clarify a few points before updating the wiki:

Currently we require a full week to elapse since the ticket was created before a decision is made. At the end of that week, if at least +3 votes are received, the proposed change is accepted. I'd like to update this phrasing to include two other cases:

  1. In the event that all nine members of FESCo votes +1 or publicly abstains, we do not need to wait for the full week. This clause should help us shortcut the process in urgent cases. Alternetely, we could reduce that to +7 to account for having up to two members be unavailable in an emergency.
  2. The week should start counting from the moment a proposal is made, not necessarily when the ticket itself is filed. For example, tickets like this one are filed sometimes to ask for FESCo's decision; we should require that a proposal be offered within a reasonable amount of time. I propose that this should be "no later than the next day that FESCo is due to send out its meeting agenda, otherwise the ticket must automatically be added to that agenda".

+1 to both additions. I like a +7 vote due to things like vacations and such.

Is the new policy described in the wiki? https://fedoraproject.org/wiki/Fedora_Engineering_Steering_Committee still seems to describe the old process.

What about changing that +3 to +5, i.e. require an absolute majority of FESCo to vote positively? This would make things more obvious, because then a decision could never be made without the majority for the change. And if there is not enough votes, just make the ticket part of the next meeting automatically.

+1 to both additions anyway, since they are orthogonal to my questions above.

Is the new policy described in the wiki? https://fedoraproject.org/wiki/Fedora_Engineering_Steering_Committee still seems to describe the old process.
What about changing that +3 to +5, i.e. require an absolute majority of FESCo to vote positively? This would make things more obvious, because then a decision could never be made without the majority for the change. And if there is not enough votes, just make the ticket part of the next meeting automatically.

The whole point of that policy was to provide incentive to vote in tickets: in essence, if you don't chime in, you lose your right to vote. Raising it to a majority and adding it to the meeting agenda would just move us back to where we were, with people not bothering to vote in tickets and the meetings lasting for hours. So, -1 on that proposal from me.

Is the new policy described in the wiki? https://fedoraproject.org/wiki/Fedora_Engineering_Steering_Committee still seems to describe the old process.

Meant to reply to this as well: I haven't updated the Wiki yet. I meant to last week and got swamped, but then realized we should clarify the points I made above and then I'll codify them all.

+1 to the additions.

In today's meeting I proposed to close tickets only once a week when writing the agenda for the next meeting and then add the decision and ticket info the the next meeting's agenda. Maybe we can also introduce a label for tickets that are already decided and are just waiting for the timeout to make this task easier. I updated https://fedoraproject.org/wiki/FESCo_meeting_process#Pre-meeting to reflect this. Does anyone have a good term to describe issues/tickets that were already discussed? I was thinking of something like off-line tickets, or off-meeting decisions? Need an English expert here. ;-)

Maybe just pending_announcement?

As an aside, I also added a tag for stalled to deal with tickets that are on our backlog but that we don't plan on revisiting for a while (like https://pagure.io/fesco/issue/1820)

I think these changes all sound reasonable, especially since I was on an airplane for today's meeting, and know that I'll be missing next week's meeting due to travel as well.

What's the status here?

What's the status here?

Status is that this was approved but we didn't process the ticket closure yet. I'll update the wiki today or tomorrow and then close this.

In today's meeting I proposed to close tickets only once a week when writing the agenda for the next meeting and then add the decision and ticket info the the next meeting's agenda. Maybe we can also introduce a label for tickets that are already decided and are just waiting for the timeout to make this task easier. I updated https://fedoraproject.org/wiki/FESCo_meeting_process#Pre-meeting to reflect this. Does anyone have a good term to describe issues/tickets that were already discussed? I was thinking of something like off-line tickets, or off-meeting decisions? Need an English expert here. ;-)

@sgallagh note if we are doing this, please don't close tickets unless you are the one sending the next meeting agenda. ;)

How about 'non-meeting decision' ? since they are already done and decided?

In today's meeting I proposed to close tickets only once a week when writing the agenda for the next meeting and then add the decision and ticket info the the next meeting's agenda. Maybe we can also introduce a label for tickets that are already decided and are just waiting for the timeout to make this task easier. I updated https://fedoraproject.org/wiki/FESCo_meeting_process#Pre-meeting to reflect this. Does anyone have a good term to describe issues/tickets that were already discussed? I was thinking of something like off-line tickets, or off-meeting decisions? Need an English expert here. ;-)

@sgallagh note if we are doing this, please don't close tickets unless you are the one sending the next meeting agenda. ;)
How about 'non-meeting decision' ? since they are already done and decided?

Sorry, I forgot about this section of the discussion when I processed tickets this morning, but we actually haven't approved that part of it. (Only the two original proposals have any votes on them).

I just updated the FESCo Wiki Page with the new ticket policy, including the clarifications I proposed in this ticket.

Let's just continue to discuss Till's proposal here.

I think I'd be a +1 for "Tickets get tagged withpending announcement when the voting is concluded and then get closed when the person organizing the agenda for the week announces it as part of that email." Does that sound reasonable to everyone, and does someone want to volunteer to update the meeting process page with a template for that?

+1 for the proposed policy

+1 for the proposal also here.

OK, the proposal has been available for more than a week and has +5, so it's accepted. From now on, we'll add the tag "pending announcement" to tickets that are approved outside of a meeting and they will be announced as part of the agenda email.

Metadata Update from @sgallagh:
- Issue tagged with: pending annonucement

4 years ago

Ha, I just closed a couple tickets that had the votes, because I hadn't yet read this. Sorry. +1 to the changes.

In addition to the above, in today's meeting we voted on the following addendum:
AGREED: The ticket policy is clarified to mean that any -1 votes automatically put the ticket on meeting agenda (as the wiki already states) (+6, 0, 0)

Announced today. @sgallagh can you update the wiki?

Metadata Update from @zbyszek:
- Issue untagged with: pending announcement
- Issue assigned to sgallagh

4 years ago

The text we voted on [https://pagure.io/fesco/issue/1921#comment-520210] was

Tickets get tagged withpending announcement when the voting is concluded and then get closed when the person organizing the agenda for the week announces it as part of that email.

I still don't see this part in the wiki.

I just added that. Sorry for the delay.

Metadata Update from @zbyszek:
- Issue close_status updated to: Accepted
- Issue status updated to: Closed (was: Open)

4 years ago

Login to comment on this ticket.

Metadata