[TC] 'V' Technical Elections
Hello! /me takes TC hat off and puts election official hat on Having run our handy dandy tool to project dates[1] for the elections, we have some decisions to make again. At this point we have threeish options: 1. Run the elections with a week in between with the TC election happening BEFORE the PTL election like the script generated. The TC election would run March 10 to March 31 and the PTL Election would run April 7 to April 21. The primary concern here is that it might lead to some election burnout. 2. Run the elections back to back with the PTL election first (closer to the historic norm). This would be tweaking the generated dates by pulling the PTL election three weeks up and pushing back the TC dates by two weeks. The PTL election would run March 3 to March 17 and the PTL Election would run March 17 to April 7. Both elections would be concluded by milestone 3. Similar concerns with this option to the first with election burnout. 3. Run the elections in parallel as a combined election, similar to how we did for the Train elections. This is much easier for election officials because we only need to generate one electorate. The two elections would start March 10 and be done by March 31 following the TC election model with a nominations period, a campaigning period (optional for PTL elections), and then a polling period (assuming we need a runoff). Other info to keep in mind when formulating your opinions: - Extra ATC deadline currently is March 23-27 which will likely need to get bumped earlier for any of these options - RC1 is the week of April 20-24 - Milestone 3 is April 9 - Release schedule for reference[2] - For TC member terms, those closing in on their ~1 year terms would be closer to 13 months since the train elections concluded March 5th of last year -Kendall (diablo_rojo) & the Election Officials [1]http://paste.openstack.org/show/787114/ [2]https://releases.openstack.org/ussuri/schedule.html
On 2019-12-04 15:01:00 -0800 (-0800), Kendall Nelson wrote: [...]
For TC member terms, those closing in on their ~1 year terms would be closer to 13 months since the train elections concluded March 5th of last year [...]
Just to clarify, this is what our (recently updated) Technical Committee Member Policy appendix to the OSF Bylaws says about TC term durations: 2.a. [...] Each Technical Committee member shall hold the seat for a term not to exceed sixteen months, but may be re-elected to the Technical Committee. After January 1, 2019, the term for the members of the Technical Committee shall be approved by a majority of the Technical Committee (“Term”) and shall be published publicly before each Technical Committee election; if no such Term is published the Term will be twelve calendar months. [...] https://www.openstack.org/legal/technical-committee-member-policy/ So those members elected in March can't actually serve past the anniversary of their elections *unless* prior to the election in which they were elected the seated TC had declared they would serve a longer term. The bylaws allow the TC to set a longer term length, but they must do so before the members who will serve that term are elected. So terms for half the TC members will be expiring at the start of March, quite possibly weeks before another TC election is held to fill their seats. This is what the TC charter seems to say: If the vacancy opens less than four weeks before the candidacy period for the next scheduled TC election begins, and the seat vacated would have been contested in the upcoming election anyway, then the seat will remain open until the election and filled by the normal election process. https://governance.openstack.org/tc/reference/charter.html So with a strict reading of the bylaws and charter wording, the TC will spend a few weeks with only 6 members until the suggested election date. There are a few options: 1. Push the TC election back further. This probably similarly implies backing the extra-ATC deadline up even more. 2. Amend the charter to allow the TC to reappoint the holders of the expired seats until the next election (I can't quite tell if this would violate the term limit wording in the bylaws, but it needs discussing). 3. Probably only a solution for 2021 and later elections, but start declaring now that TC seat terms are something like "14 months or until the date of the next election" so that the TC doesn't need to predict election timing more than a year in advance (OSF bylaws authorize us to make it up to 16 months for that matter). -- Jeremy Stanley
On 12/4/2019 5:39 PM, Jeremy Stanley wrote:
On 2019-12-04 15:01:00 -0800 (-0800), Kendall Nelson wrote: [...]
For TC member terms, those closing in on their ~1 year terms would be closer to 13 months since the train elections concluded March 5th of last year [...]
Just to clarify, this is what our (recently updated) Technical Committee Member Policy appendix to the OSF Bylaws says about TC term durations:
2.a. [...] Each Technical Committee member shall hold the seat for a term not to exceed sixteen months, but may be re-elected to the Technical Committee. After January 1, 2019, the term for the members of the Technical Committee shall be approved by a majority of the Technical Committee (“Term”) and shall be published publicly before each Technical Committee election; if no such Term is published the Term will be twelve calendar months. [...]
https://www.openstack.org/legal/technical-committee-member-policy/
So those members elected in March can't actually serve past the anniversary of their elections *unless* prior to the election in which they were elected the seated TC had declared they would serve a longer term. The bylaws allow the TC to set a longer term length, but they must do so before the members who will serve that term are elected.
So terms for half the TC members will be expiring at the start of March, quite possibly weeks before another TC election is held to fill their seats. This is what the TC charter seems to say:
If the vacancy opens less than four weeks before the candidacy period for the next scheduled TC election begins, and the seat vacated would have been contested in the upcoming election anyway, then the seat will remain open until the election and filled by the normal election process.
https://governance.openstack.org/tc/reference/charter.html
So with a strict reading of the bylaws and charter wording, the TC will spend a few weeks with only 6 members until the suggested election date. There are a few options:
1. Push the TC election back further. This probably similarly implies backing the extra-ATC deadline up even more. I am guessing that this is hard for the election committee and seems to avoid the fact that we seem to have more widely varying release schedules.
2. Amend the charter to allow the TC to reappoint the holders of the expired seats until the next election (I can't quite tell if this would violate the term limit wording in the bylaws, but it needs discussing). I think for this particular case it is worth discussing and is something we maybe want to formalize for the future in case other unexpected circumstances arise. 3. Probably only a solution for 2021 and later elections, but start declaring now that TC seat terms are something like "14 months or until the date of the next election" so that the TC doesn't need to predict election timing more than a year in advance (OSF bylaws authorize us to make it up to 16 months for that matter).
I would support this change in the future or we could combine 2 and 3 such that they have a 14 month term or until the date of the next election. If the next election is beyond 14 months the TC can reappoint the holders until the election can be held. That would be a catch all. Jay
On 2019-12-04 23:22:33 -0600 (-0600), Jay Bryant wrote:
On 12/4/2019 5:39 PM, Jeremy Stanley wrote: [...]
1. Push the TC election back further. This probably similarly implies backing the extra-ATC deadline up even more.
I am guessing that this is hard for the election committee and seems to avoid the fact that we seem to have more widely varying release schedules.
It's not really significantly harder on the election officials, but does possibly present challenges for the community if they need to identify additional extra-ATCs in advance of the TC election as they'd need to do it by, like, Ussuri milestone 2. -- Jeremy Stanley
On 12/4/19 5:39 PM, Jeremy Stanley wrote:
Just to clarify, this is what our (recently updated) Technical Committee Member Policy appendix to the OSF Bylaws says about TC term durations:
2.a. [...] Each Technical Committee member shall hold the seat for a term not to exceed sixteen months, but may be re-elected to the Technical Committee. After January 1, 2019, the term for the members of the Technical Committee shall be approved by a majority of the Technical Committee (“Term”) and shall be published publicly before each Technical Committee election; if no such Term is published the Term will be twelve calendar months. [...]
"published publicly before each TC election" ... stick a pin here for below... [...]
3. Probably only a solution for 2021 and later elections, but start declaring now that TC seat terms are something like "14 months or until the date of the next election" so that the TC doesn't need to predict election timing more than a year in advance (OSF bylaws authorize us to make it up to 16 months for that matter).
I recall this being the intent when the charter was last updated. Unless I am conflating this with StarlingX where we had similar discussions when setting up governance. I think it is the "published before" language that is the real issue. The terms have never been exactly 6 or 12 months and in practice the membership changes were made soon after the close of the election. Relaxing the wording to just refer to the (roughly) 6 month election cycle as the bounds for terms achieves both the historical practice and what I have always thought was the community consensus. This way the only time that terms would expire and seats be left unfilled is if the elections were to be delayed long enough for the OSF bylaws limit of 16 months to be reached. Summary: a) Given that elections hare held (roughly) every 6 months for all PTLs and approximately half of the TC; b) Define terms as running from the close and certification of an elections results until the close and certification of the next applicable election for a given seat, ie the next election about 6 months later for PTL terms and the second-following election about 12 months later for TC terms. dt -- Dean Troyer dtroyer@gmail.com
On Thu, Dec 05, 2019 at 06:39:37PM -0600, Dean Troyer wrote:
On 12/4/19 5:39 PM, Jeremy Stanley wrote:
Just to clarify, this is what our (recently updated) Technical Committee Member Policy appendix to the OSF Bylaws says about TC term durations:
2.a. [...] Each Technical Committee member shall hold the seat for a term not to exceed sixteen months, but may be re-elected to the Technical Committee. After January 1, 2019, the term for the members of the Technical Committee shall be approved by a majority of the Technical Committee (“Term”) and shall be published publicly before each Technical Committee election; if no such Term is published the Term will be twelve calendar months. [...]
"published publicly before each TC election" ... stick a pin here for below...
[...]
3. Probably only a solution for 2021 and later elections, but start declaring now that TC seat terms are something like "14 months or until the date of the next election" so that the TC doesn't need to predict election timing more than a year in advance (OSF bylaws authorize us to make it up to 16 months for that matter).
I recall this being the intent when the charter was last updated. Unless I am conflating this with StarlingX where we had similar discussions when setting up governance.
That was my recollection as well. I think we had "not to exceed 16 months" as a way to have some flexibility because we knew that generally terms would be slightly longer than 12 months. The later phrasing of "will be twelve months" is the tricky part here, since that is what we ended up publishing. I don't recall it being our intent to have a strict 12 month term.
On 2019-12-06 06:53:31 -0600 (-0600), Sean McGinnis wrote: [...]
The later phrasing of "will be twelve months" is the tricky part here, since that is what we ended up publishing. I don't recall it being our intent to have a strict 12 month term.
Yep, that's really the present challenge. The TC needs to have something in the charter which declares a longer (or maybe also shorter) possible term length. Otherwise they get the default "12 months" from the bylaws. They *can* work with the board to change that part of the bylaws more easily now, it no longer needs scheduling a vote of the OSF members and nail-biting over getting sufficient voter turnout at least, but it does still mean board meetings and similar lengthy process (compared to bylaws changes which the TC can in theory propose and approve within a week or so if they're quick to register their votes on it). So anyway, there's the rub, if the TC can fix this before March then the members elected in 2020 Q1 will not be subject to the same scheduling complications when their terms expire in 2021 Q1, but we're still going to have to deal with this problem through both 2020 elections I suspect. -- Jeremy Stanley
On 2019-12-06 15:45:53 +0000 (+0000), Jeremy Stanley wrote: [...]
They *can* work with the board to change that part of the bylaws more easily now, it no longer needs scheduling a vote of the OSF members and nail-biting over getting sufficient voter turnout at least, but it does still mean board meetings and similar lengthy process (compared to bylaws changes which the TC can in theory propose and approve within a week or so if they're quick to register their votes on it). [...]
Just for clarification, I meant to say "...compared to CHARTER changes which the TC can in theory propose and approve within a week or so..." -- Jeremy Stanley
Tangential to election scheduling but still on the topic of election planning, last cycle a bunch of folks jumped on the "let's shrink the TC!" bandwagon *while* the election process was already underway. That was of course not an appropriate time to talk about changes to election parameters. But now(ish) *is* the right time. So to reopen that discussion we previously put a pin in, how many TC seats should we fill in the coming election, and how many should we delete? There were a few different suggestions, some following a less aggressive timeline than others. We would normally have 7 seats up for grabs in the coming round... do we reduce it to 6 (and work with an even-number-sized TC), or just 5 (targeting a TC of 11 for Ussuri into "V")? Or something even more drastic like just letting them all expire and filling none, immediately down-sizing to a TC of 6 members? Thoughts? -- Jeremy Stanley
On 4/12/19 6:50 pm, Jeremy Stanley wrote:
Tangential to election scheduling but still on the topic of election planning, last cycle a bunch of folks jumped on the "let's shrink the TC!" bandwagon *while* the election process was already underway. That was of course not an appropriate time to talk about changes to election parameters. But now(ish) *is* the right time.
So to reopen that discussion we previously put a pin in, how many TC seats should we fill in the coming election, and how many should we delete? There were a few different suggestions, some following a less aggressive timeline than others. We would normally have 7 seats up for grabs in the coming round... do we reduce it to 6 (and work with an even-number-sized TC), or just 5 (targeting a TC of 11 for Ussuri into "V")? Or something even more drastic like just letting them all expire and filling none, immediately down-sizing to a TC of 6 members? Thoughts?
This is pretty well-settled: https://review.opendev.org/681266 (At least assuming we ignore the fact that JP merged it when it had only 8 of the 9 required votes, which I only just noticed. Naughty JP.)
On Wed, 2019-12-04 at 22:18 -0500, Zane Bitter wrote:
On 4/12/19 6:50 pm, Jeremy Stanley wrote:
Tangential to election scheduling but still on the topic of election planning, last cycle a bunch of folks jumped on the "let's shrink the TC!" bandwagon *while* the election process was already underway. That was of course not an appropriate time to talk about changes to election parameters. But now(ish) *is* the right time.
So to reopen that discussion we previously put a pin in, how many TC seats should we fill in the coming election, and how many should we delete? There were a few different suggestions, some following a less aggressive timeline than others. We would normally have 7 seats up for grabs in the coming round... do we reduce it to 6 (and work with an even-number-sized TC), or just 5 (targeting a TC of 11 for Ussuri into "V")? Or something even more drastic like just letting them all expire and filling none, immediately down-sizing to a TC of 6 members? Thoughts?
This is pretty well-settled:
https://review.opendev.org/681266
(At least assuming we ignore the fact that JP merged it when it had only 8 of the 9 required votes, which I only just noticed. Naughty JP.)
You know I like being naughty! However, I don't think I was it this time: For a TC of 13 members, 7 is the simple majority. We had consensus too :) I wrote this email to (shameless plug) remind that only 5 votes are technically required for motions when we have 13 members [1], but I generally try to reach the simple majority if possible. Regards, JP [1]: https://governance.openstack.org/tc/reference/charter.html#motions
On 5/12/19 6:26 am, Jean-Philippe Evrard wrote:
On Wed, 2019-12-04 at 22:18 -0500, Zane Bitter wrote:
On 4/12/19 6:50 pm, Jeremy Stanley wrote:
Tangential to election scheduling but still on the topic of election planning, last cycle a bunch of folks jumped on the "let's shrink the TC!" bandwagon *while* the election process was already underway. That was of course not an appropriate time to talk about changes to election parameters. But now(ish) *is* the right time.
So to reopen that discussion we previously put a pin in, how many TC seats should we fill in the coming election, and how many should we delete? There were a few different suggestions, some following a less aggressive timeline than others. We would normally have 7 seats up for grabs in the coming round... do we reduce it to 6 (and work with an even-number-sized TC), or just 5 (targeting a TC of 11 for Ussuri into "V")? Or something even more drastic like just letting them all expire and filling none, immediately down-sizing to a TC of 6 members? Thoughts?
This is pretty well-settled:
https://review.opendev.org/681266
(At least assuming we ignore the fact that JP merged it when it had only 8 of the 9 required votes, which I only just noticed. Naughty JP.)
You know I like being naughty! However, I don't think I was it this time: For a TC of 13 members, 7 is the simple majority. We had consensus too :)
But amending the charter itself requires 2/3 majority: https://governance.openstack.org/tc/reference/charter.html#amendment
I wrote this email to (shameless plug) remind that only 5 votes are technically required for motions when we have 13 members [1], but I generally try to reach the simple majority if possible.
Regards, JP
[1]: https://governance.openstack.org/tc/reference/charter.html#motions
On 5/12/19 9:05 am, Zane Bitter wrote:
On 5/12/19 6:26 am, Jean-Philippe Evrard wrote:
On Wed, 2019-12-04 at 22:18 -0500, Zane Bitter wrote:
On 4/12/19 6:50 pm, Jeremy Stanley wrote:
Tangential to election scheduling but still on the topic of election planning, last cycle a bunch of folks jumped on the "let's shrink the TC!" bandwagon *while* the election process was already underway. That was of course not an appropriate time to talk about changes to election parameters. But now(ish) *is* the right time.
So to reopen that discussion we previously put a pin in, how many TC seats should we fill in the coming election, and how many should we delete? There were a few different suggestions, some following a less aggressive timeline than others. We would normally have 7 seats up for grabs in the coming round... do we reduce it to 6 (and work with an even-number-sized TC), or just 5 (targeting a TC of 11 for Ussuri into "V")? Or something even more drastic like just letting them all expire and filling none, immediately down-sizing to a TC of 6 members? Thoughts?
This is pretty well-settled:
https://review.opendev.org/681266
(At least assuming we ignore the fact that JP merged it when it had only 8 of the 9 required votes, which I only just noticed. Naughty JP.)
You know I like being naughty! However, I don't think I was it this time: For a TC of 13 members, 7 is the simple majority. We had consensus too :)
But amending the charter itself requires 2/3 majority:
https://governance.openstack.org/tc/reference/charter.html#amendment
Closing the loop on this, we got 3 more TC members to retroactively comment with their approval, so the rules are satisfied. I proposed a tweak to the documentation to help remind us that we should use the `charter-change` tag rather than `formal-vote` in future - it's currently easy to miss because of the non-locality of the documentation sections describing them: https://review.opendev.org/697511 - ZB
Hello Everyone! To summarize the TC office hours discussions today[1]: - The majority of folks are in favor of a combined election - With the combined election dates above, those TC members seat that will be up for reelection will hit their term limite before we conclude the election so there will be a period of time where the TC will only be 6 members until the election concludes. - In an effor to avoid this expiration and gap in having a full TC in the future, we want to amend the charter to say something about term limits being '14 months or when the second election since being elected concludes' or something like that-- theres another thread for that discussion '[TC] Election Terms' - We will need to move the extra-atc deadline forward so that it is during the week of nominations so that they can be included in the electorates I think that covers all of it. If I missed anything, please feel free to expand :) If we, the election officials don't hear anything by the end of next week, we will move froward updating the election site and the release schedule. -Kendall [1] http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2019-... On Wed, Dec 4, 2019 at 3:01 PM Kendall Nelson <kennelson11@gmail.com> wrote:
Hello!
/me takes TC hat off and puts election official hat on
Having run our handy dandy tool to project dates[1] for the elections, we have some decisions to make again.
At this point we have threeish options:
1. Run the elections with a week in between with the TC election happening BEFORE the PTL election like the script generated. The TC election would run March 10 to March 31 and the PTL Election would run April 7 to April 21. The primary concern here is that it might lead to some election burnout.
2. Run the elections back to back with the PTL election first (closer to the historic norm). This would be tweaking the generated dates by pulling the PTL election three weeks up and pushing back the TC dates by two weeks. The PTL election would run March 3 to March 17 and the PTL Election would run March 17 to April 7. Both elections would be concluded by milestone 3. Similar concerns with this option to the first with election burnout.
3. Run the elections in parallel as a combined election, similar to how we did for the Train elections. This is much easier for election officials because we only need to generate one electorate. The two elections would start March 10 and be done by March 31 following the TC election model with a nominations period, a campaigning period (optional for PTL elections), and then a polling period (assuming we need a runoff).
Other info to keep in mind when formulating your opinions: - Extra ATC deadline currently is March 23-27 which will likely need to get bumped earlier for any of these options - RC1 is the week of April 20-24 - Milestone 3 is April 9 - Release schedule for reference[2] - For TC member terms, those closing in on their ~1 year terms would be closer to 13 months since the train elections concluded March 5th of last year
-Kendall (diablo_rojo) & the Election Officials
[1]http://paste.openstack.org/show/787114/ [2]https://releases.openstack.org/ussuri/schedule.html
On Thu, Dec 05, 2019 at 11:15:45PM -0800, Kendall Nelson wrote:
Hello Everyone!
To summarize the TC office hours discussions today[1]:
- The majority of folks are in favor of a combined election - With the combined election dates above, those TC members seat that will be up for reelection will hit their term limite before we conclude the election so there will be a period of time where the TC will only be 6 members until the election concludes. - In an effor to avoid this expiration and gap in having a full TC in the future, we want to amend the charter to say something about term limits being '14 months or when the second election since being elected concludes' or something like that-- theres another thread for that discussion '[TC] Election Terms'
Rather than stating an exact term length and running the risk of ending up in a similar situation in the future, I would recommend just stating term limits will be 'a minimum of 12 months not to exceed 16 months, based on when the next election aligns with overall community activities.'
On 12/6/19 6:56 AM, Sean McGinnis wrote:
On Thu, Dec 05, 2019 at 11:15:45PM -0800, Kendall Nelson wrote:
Hello Everyone!
To summarize the TC office hours discussions today[1]:
- The majority of folks are in favor of a combined election - With the combined election dates above, those TC members seat that will be up for reelection will hit their term limite before we conclude the election so there will be a period of time where the TC will only be 6 members until the election concludes. - In an effor to avoid this expiration and gap in having a full TC in the future, we want to amend the charter to say something about term limits being '14 months or when the second election since being elected concludes' or something like that-- theres another thread for that discussion '[TC] Election Terms'
Rather than stating an exact term length and running the risk of ending up in a similar situation in the future, I would recommend just stating term limits will be 'a minimum of 12 months not to exceed 16 months, based on when the next election aligns with overall community activities.'
The point I was making in another fork of this thread was to tie the exact term length to the election timing and only state approximate lengths here, ie including 'minimum' in the above will still set a bound that complicates accommodating another slightly smaller than usual cycle. dt -- Dean Troyer dtroyer@gmail.com
<snip>
The point I was making in another fork of this thread was to tie the exact term length to the election timing and only state approximate lengths here, ie including 'minimum' in the above will still set a bound that complicates accommodating another slightly smaller than usual cycle.
</snip> I am in agreement with Dean that the easiest and most flexible solution is to tie the term lengths to the elections and not state a particular minimum or maximum. Thank you for proposing this solution! Jay
dt
On 2019-12-06 12:54:00 -0600 (-0600), Jay Bryant wrote:
<snip>
The point I was making in another fork of this thread was to tie the exact term length to the election timing and only state approximate lengths here, ie including 'minimum' in the above will still set a bound that complicates accommodating another slightly smaller than usual cycle.
</snip>
I am in agreement with Dean that the easiest and most flexible solution is to tie the term lengths to the elections and not state a particular minimum or maximum. [...]
Does this satisfy what's required by the bylaws though? the term for the members of the Technical Committee shall be approved by a majority of the Technical Committee (“Term”) and shall be published publicly before each Technical Committee election; if no such Term is published the Term will be twelve calendar months. https://www.openstack.org/legal/technical-committee-member-policy/ I guess it doesn't *strictly* require a term duration to be specified as an explicit measure of time, so it's possible to interpret it as allowing terms to be defined according to some other criteria as long as they don't also exceed 16 months. -- Jeremy Stanley
---- On Fri, 06 Dec 2019 14:02:07 -0600 Jeremy Stanley <fungi@yuggoth.org> wrote ----
On 2019-12-06 12:54:00 -0600 (-0600), Jay Bryant wrote:
<snip>
The point I was making in another fork of this thread was to tie the exact term length to the election timing and only state approximate lengths here, ie including 'minimum' in the above will still set a bound that complicates accommodating another slightly smaller than usual cycle.
</snip>
I am in agreement with Dean that the easiest and most flexible solution is to tie the term lengths to the elections and not state a particular minimum or maximum. [...]
Does this satisfy what's required by the bylaws though?
the term for the members of the Technical Committee shall be approved by a majority of the Technical Committee (“Term”) and shall be published publicly before each Technical Committee election; if no such Term is published the Term will be twelve calendar months.
https://www.openstack.org/legal/technical-committee-member-policy/
I guess it doesn't *strictly* require a term duration to be specified as an explicit measure of time, so it's possible to interpret it as allowing terms to be defined according to some other criteria as long as they don't also exceed 16 months.
I agree with mapping the TC term with the election. bylaws say: " the elections for the Technical Committee shall be held in two phases: the first election being for at least half of the members of the Technical Committee and the second election being for the remaining members of Technical Committee." Because Elections dates are not explicitly mentioned (as we do not know the future events final dates) and are divided into two-phase. Current TC charter states 'The election is held no later than 6 weeks prior to each OpenStack Summit' which makes the term length etc tricky. If we can define the specific week for both phases then it can be consistent. I feel R-4 can be fixed week: - 4th weeks prior to each cycle final release date (R-4) is the fixed week to conduct the election. - And make PTL and TC election as a combine election always at R-4. TC term can be documented as a "two-cycle term". [2] https://governance.openstack.org/tc/reference/charter.html -gmann
-- Jeremy Stanley
On Mon, Dec 9, 2019 at 10:13 AM Ghanshyam Mann <gmann@ghanshyammann.com> wrote:
---- On Fri, 06 Dec 2019 14:02:07 -0600 Jeremy Stanley <fungi@yuggoth.org> wrote ----
On 2019-12-06 12:54:00 -0600 (-0600), Jay Bryant wrote:
<snip>
The point I was making in another fork of this thread was to tie the exact term length to the election timing and only state approximate lengths here, ie including 'minimum' in the above will still set a bound that complicates accommodating another slightly smaller than usual cycle.
</snip>
I am in agreement with Dean that the easiest and most flexible solution is to tie the term lengths to the elections and not state a particular minimum or maximum. [...]
Does this satisfy what's required by the bylaws though?
the term for the members of the Technical Committee shall be approved by a majority of the Technical Committee (“Term”) and shall be published publicly before each Technical Committee election; if no such Term is published the Term will be twelve calendar months.
https://www.openstack.org/legal/technical-committee-member-policy/
I guess it doesn't *strictly* require a term duration to be specified as an explicit measure of time, so it's possible to interpret it as allowing terms to be defined according to some other criteria as long as they don't also exceed 16 months.
I agree with mapping the TC term with the election.
bylaws say: " the elections for the Technical Committee shall be held in two phases: the first election being for at least half of the members of the Technical Committee and the second election being for the remaining members of Technical Committee."
Because Elections dates are not explicitly mentioned (as we do not know the future events final dates) and are divided into two-phase. Current TC charter states 'The election is held no later than 6 weeks prior to each OpenStack Summit' which makes the term length etc tricky. If we can define the specific week for both phases then it can be consistent.
Just throwing this idea out there (its probably already been discussed at some point).. but what if we just tie it to releases instead of to events since events are way more variable than releases? -Kendall (diablo_rojo)
I feel R-4 can be fixed week: - 4th weeks prior to each cycle final release date (R-4) is the fixed week to conduct the election. - And make PTL and TC election as a combine election always at R-4.
TC term can be documented as a "two-cycle term".
[2] https://governance.openstack.org/tc/reference/charter.html
-gmann
-- Jeremy Stanley
On 12/9/2019 12:41 PM, Kendall Nelson wrote:
On Mon, Dec 9, 2019 at 10:13 AM Ghanshyam Mann <gmann@ghanshyammann.com <mailto:gmann@ghanshyammann.com>> wrote:
---- On Fri, 06 Dec 2019 14:02:07 -0600 Jeremy Stanley <fungi@yuggoth.org <mailto:fungi@yuggoth.org>> wrote ---- > On 2019-12-06 12:54:00 -0600 (-0600), Jay Bryant wrote: > > <snip> > > > The point I was making in another fork of this thread was to tie the > > > exact term length to the election timing and only state approximate > > > lengths here, ie including 'minimum' in the above will still set a bound > > > that complicates accommodating another slightly smaller than usual > > > cycle. > > > > > </snip> > > > > I am in agreement with Dean that the easiest and most flexible > > solution is to tie the term lengths to the elections and not state > > a particular minimum or maximum. > [...] > > Does this satisfy what's required by the bylaws though? > > the term for the members of the Technical Committee shall be > approved by a majority of the Technical Committee (“Term”) and > shall be published publicly before each Technical Committee > election; if no such Term is published the Term will be twelve > calendar months. > > https://www.openstack.org/legal/technical-committee-member-policy/ > > I guess it doesn't *strictly* require a term duration to be > specified as an explicit measure of time, so it's possible to > interpret it as allowing terms to be defined according to some other > criteria as long as they don't also exceed 16 months.
I agree with mapping the TC term with the election.
bylaws say: " the elections for the Technical Committee shall be held in two phases: the first election being for at least half of the members of the Technical Committee and the second election being for the remaining members of Technical Committee."
Because Elections dates are not explicitly mentioned (as we do not know the future events final dates) and are divided into two-phase. Current TC charter states 'The election is held no later than 6 weeks prior to each OpenStack Summit' which makes the term length etc tricky. If we can define the specific week for both phases then it can be consistent.
Just throwing this idea out there (its probably already been discussed at some point).. but what if we just tie it to releases instead of to events since events are way more variable than releases?
-Kendall (diablo_rojo)
Good point. Given the recent changes and the fact that even schedules have become more variable, it may make sense to follow the release schedule that is remaining relatively static. Jay
I feel R-4 can be fixed week: - 4th weeks prior to each cycle final release date (R-4) is the fixed week to conduct the election. - And make PTL and TC election as a combine election always at R-4.
TC term can be documented as a "two-cycle term".
[2] https://governance.openstack.org/tc/reference/charter.html
-gmann
> -- > Jeremy Stanley >
---- On Fri, 06 Dec 2019 01:15:45 -0600 Kendall Nelson <kennelson11@gmail.com> wrote ----
Hello Everyone!
To summarize the TC office hours discussions today[1]: - The majority of folks are in favor of a combined election- With the combined election dates above, those TC members seat that will be up for reelection will hit their term limite before we conclude the election so there will be a period of time where the TC will only be 6 members until the election concludes. - In an effor to avoid this expiration and gap in having a full TC in the future, we want to amend the charter to say something about term limits being '14 months or when the second election since being elected concludes' or something like that-- theres another thread for that discussion '[TC] Election Terms'- We will need to move the extra-atc deadline forward so that it is during the week of nominations so that they can be included in the electorates I think that covers all of it. If I missed anything, please feel free to expand :)
I think that is all. During the half-tc period, we will not be able to merge any charter change which should be ok. -gmann
If we, the election officials don't hear anything by the end of next week, we will move froward updating the election site and the release schedule. -Kendall [1] http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2019-... On Wed, Dec 4, 2019 at 3:01 PM Kendall Nelson <kennelson11@gmail.com> wrote: Hello!
/me takes TC hat off and puts election official hat on
Having run our handy dandy tool to project dates[1] for the elections, we have some decisions to make again.
At this point we have threeish options:
1. Run the elections with a week in between with the TC election happening BEFORE the PTL election like the script generated. The TC election would run March 10 to March 31 and the PTL Election would run April 7 to April 21. The primary concern here is that it might lead to some election burnout.
2. Run the elections back to back with the PTL election first (closer to the historic norm). This would be tweaking the generated dates by pulling the PTL election three weeks up and pushing back the TC dates by two weeks. The PTL election would run March 3 to March 17 and the PTL Election would run March 17 to April 7. Both elections would be concluded by milestone 3. Similar concerns with this option to the first with election burnout.
3. Run the elections in parallel as a combined election, similar to how we did for the Train elections. This is much easier for election officials because we only need to generate one electorate. The two elections would start March 10 and be done by March 31 following the TC election model with a nominations period, a campaigning period (optional for PTL elections), and then a polling period (assuming we need a runoff).
Other info to keep in mind when formulating your opinions: - Extra ATC deadline currently is March 23-27 which will likely need to get bumped earlier for any of these options - RC1 is the week of April 20-24 - Milestone 3 is April 9 - Release schedule for reference[2] - For TC member terms, those closing in on their ~1 year terms would be closer to 13 months since the train elections concluded March 5th of last year -Kendall (diablo_rojo) & the Election Officials
[1]http://paste.openstack.org/show/787114/ [2]https://releases.openstack.org/ussuri/schedule.html
On 2019-12-06 09:08:19 -0600 (-0600), Ghanshyam Mann wrote: [...]
I think that is all. During the half-tc period, we will not be able to merge any charter change which should be ok. [...]
That is true if using a conservative interpretation of the TC Charter's wording, which I think is appropriate to err on the side of caution. However it *does* then follow that any changes needed in the charter to address scheduling challenges for 2021 elections must have their voting finalized before those other 7 members' terms expire. -- Jeremy Stanley
On Wed, Dec 04, 2019 at 03:01:00PM -0800, Kendall Nelson wrote:
Hello!
/me takes TC hat off and puts election official hat on
Having run our handy dandy tool to project dates[1] for the elections, we have some decisions to make again.
/me catches up. If whomever wrote the election guessing tool had documented it things would look better Who was it .... and moving right along. [tony@thor election]$ (tox -e venv setup-election-config -- 2020-06-08 v-release TC ; tox -e venv setup-election-config -- 2020-05-13 v-release PTL) | pastebinit http://paste.openstack.org/show/787485 Which looks more like: TC Election from 2020-04-14T23:45 to 2020-04-21T23:45 TC Campaigning from 2020-04-07T23:45 to 2020-04-14T23:45 TC Nominations from 2020-03-31T23:45 to 2020-04-07T23:45 Set email_deadline to 2020-04-07T00:00 PTL Election from 2020-04-14T23:45 to 2020-04-21T23:45 PTL Nominations from 2020-04-07T23:45 to 2020-04-14T23:45 Set email_deadline to 2020-04-07T00:00 So if we Leave the email deadline at: 2020-04-07 00:00 and move the PTL election out to be the same time as the TC election then we trivially have a combined election. We don't need to move the extra-ATC date as that's already prior to the email deadline. Set email_deadline to 2020-04-07T00:00 Nominations from 2020-03-31T23:45 to 2020-04-07T23:45 Campaigning from 2020-04-07T23:45 to 2020-04-14T23:45 Election from 2020-04-14T23:45 to 2020-04-21T23:45 According to: https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_6c71f84caff2b37c The TC election closed on 06/03/2019, 10:45:23, so given a 16month term (as described in https://www.openstack.org/legal/technical-committee-member-policy/) we're okay to maintain the TC as is. The net result is that *current* PTLs have to serve for an "extra" week. /me will probably regret not reading the whole thread before replying Yours Tony.
On 2019-12-18 13:03:26 +1100 (+1100), Tony Breeds wrote: [...]
Election from 2020-04-14T23:45 to 2020-04-21T23:45
According to: https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_6c71f84caff2b37c
The TC election closed on 06/03/2019, 10:45:23, so given a 16month term (as described in https://www.openstack.org/legal/technical-committee-member-policy/) we're okay to maintain the TC as is.
The net result is that *current* PTLs have to serve for an "extra" week.
/me will probably regret not reading the whole thread before replying
I'm a tl;dr it all for ya: bylaws say the TC can declare a term that's up to 16 months, but if they don't specify it prior to the election for that term (which they didn't) then it defaults to 12 and what you have there is (accounting for your curious way of writing 2019-03-05T23:45:23UTC) is a ~13.5 month term. In order to avoid needing a special election to fill the expired terms for ~6 weeks until the election, we need to pull it in by at least a couple weeks (because the charter will allow those seats to remain vacant if the open up within a month of a scheduled election). Clear as mud? ;) -- Jeremy Stanley
participants (9)
-
Dean Troyer
-
Ghanshyam Mann
-
Jay Bryant
-
Jean-Philippe Evrard
-
Jeremy Stanley
-
Kendall Nelson
-
Sean McGinnis
-
Tony Breeds
-
Zane Bitter