I believe we should fix the election calendar to ensure it is predictable and not affected by release ships, such as the one we currently had.

Can you elaborate on why this is actually a problem?

We could define the terms of office to begin with the release changes.

I don't understand what you mean by this.

The current way we plan elections is intentional. At least for FESCo and Council we are electing representatives for two Fedora release periods. As such we need to have the Elections period after a Fedora release is made GA and shift the Elections period if a Fedora release slips.

If we would like to have Elections decoupled from Fedora release schedule, we need to have the mandate of representatives also decoupled from the Fedora release period, which (at least for FESCo) does not make sense for me.

I am suggesting we fix the election activity so that it doesn't have to be rescheduled when there is a slip in the release. That makes it predictable. The period of service doesn't need to be affected.

For example, the US elects Presidents in November every 4 years, but they don't start service until January in the following year.

i.e. we don't have a vote over the 4th quarter holidays problem anymore

The current way we plan elections is intentional. At least for FESCo and Council we are electing representatives for two Fedora release periods. As such we need to have the Elections period after a Fedora release is made GA and shift the Elections period if a Fedora release slips.
If we would like to have Elections decoupled from Fedora release schedule, we need to have the mandate of representatives also decoupled from the Fedora release period, which (at least for FESCo) does not make sense for me.

I do not believe the period of service and the date of the election need to be related.

I am suggesting we fix the election activity so that it doesn't have to be rescheduled when there is a slip in the release. That makes it predictable. The period of service doesn't need to be affected.

So you're suggesting to hold the election on a prescribed timeframe, but defer service start until a release boundary, correct?

For example, the US elects Presidents in November every 4 years, but they don't start service until January in the following year.
i.e. we don't have a vote over the 4th quarter holidays problem anymore

How does that not introduce an "elections while in the middle of getting a slip out the door" problem?

I'm not really sure I believe a holiday voting period is really a problem. The election turnouts have been consistent from election to election for a few years now, regardless of when they are held.

I do not believe the period of service and the date of the election need to be related.

For Fedora Council, there's not a strong reason. There's an arguably-stronger one for FESCo, to help with release continuity, but as we a) are starting to plan earlier, with F26 change requests already approved and b) are hopefully thinking bigger than just the release cycle at the FESCo level too, maybe that's not so important either.

If we're going to a calendar schedule, I'd suggest February/March (around/after DevConf) and August/September (around/after Flock).

I have read all the thoughts about this topic, but probably I'm too traditional...I cannot see any strong pro on having elections in a fixed date, just because we want to plan something. I can even see cons when having stepping down members in place for another month: are they still serving the Project as before?
(other countries for example also don't handle elections and terms of office like the US, so let's not take politics as background and do our own thing)

IMO we should not become too much encounters here, let's keep flexibility and setup elections as always, getting new elected members into their body just after the result announcement and not one month later or more.

Why shouldn't we change other than because "change"? (Presuming there are benefits to be gained from the change of some level.)

@robyduck has mentioned concerns about having newly elected people in existence while others finish their term. Are there other reasons?

On the positive side, I see:

• The newly elected can look over shoulders of the current folks or shadow them to prepare for their roles

• This creates a potential consulted group for decisions being undertaken that take effect after the current term expires (i.e. F26 changes submitted to the f25 FESCo)

• Fixing the election dates would allow us to create more of an event around the elections and hopefully improve both voter turn out and nominations. Additionally we could ensure that elections don't occur during known busy periods or over holidays necessitating last minute corrections.

Why shouldn't we change other than because "change"? (Presuming there are benefits to be gained from the change of some level.)
@robyduck has mentioned concerns about having newly elected people in existence while others finish their term. Are there other reasons?
On the positive side, I see:

The newly elected can look over shoulders of the current folks or shadow them to prepare for their roles

There is nothing that prevents them from doing so now. We have said consistently that you e.g. do not have to be on FESCo to actually do FESCo work. Frankly put, people being elected to a position should be elected because they have proven they are capable of leading and filling the role.

Please do not let the fact that we have elections confuse the fact that Fedora remains a meritocracy in most aspects. Typically one should already be doing the work before they get the position. The fact that we need elections is a testament to how many people we have already working at that level.

This creates a potential consulted group for decisions being undertaken that take effect after the current term expires (i.e. F26 changes submitted to the f25 FESCo)

This exists regardless of when Elections are. Non-committee members are and should be consulted on a regular basis or you get echo chambers.

Fixing the election dates would allow us to create more of an event around the elections and hopefully improve both voter turn out and nominations. Additionally we could ensure that elections don't occur during known busy periods or over holidays necessitating last minute corrections.

As I previously said, I disagree completely that this is a concern.

So you ask the question 'Why shouldn't we change other than because "change"?' but all I see here is change for the sake of change.

I'm very -1 to moving to a fixed election cycle across the project. If there are groups that would benefit from doing so, then they can make individual cases for it. The technical groups tied to our actual release cycle do not benefit from fixed dates.

In meeting today, jkurik was also -1, and so is robyduck. Langdon is a -0.2. :) Bex says he still thinks it is a good idea but not a priority. I'm going to call this declined.