[infra] Elections for Airship
OpenStack Infra team,
As the Airship project works to finalize our governance and elected positions [1], we need to be ready to hold our first elections. I wanted to reach out and ask for any experience, guidance, materials, or tooling you can share that would help this run correctly and smoothly? This is an area where the Airship team doesn't have much experience so we may not know the right questions to ask.
Aside from a member of the Airship community creating a poll in CIVS [2], is there anything else you would recommend? Is there any additional tooling in place in the OpenStack world? Any potential pitfalls, or other hard-won advice for us?
[1] https://review.opendev.org/#/c/653865/ [2] https://civs.cs.cornell.edu/
Thank you for your help! Matt
On Thu, May 30, 2019 at 07:04:56PM +0000, MCEUEN, MATT wrote:
OpenStack Infra team,
As the Airship project works to finalize our governance and elected positions [1], we need to be ready to hold our first elections. I wanted to reach out and ask for any experience, guidance, materials, or tooling you can share that would help this run correctly and smoothly? This is an area where the Airship team doesn't have much experience so we may not know the right questions to ask.
Aside from a member of the Airship community creating a poll in CIVS [2], is there anything else you would recommend? Is there any additional tooling in place in the OpenStack world? Any potential pitfalls, or other hard-won advice for us?
[1] https://review.opendev.org/#/c/653865/ [2] https://civs.cs.cornell.edu/
Thank you for your help! Matt
Hey Matt,
You might be able to find some useful process information and some tooling for how the OpenStack community has done elections here:
https://opendev.org/openstack/election
Sean
On 2019-05-30 19:04:56 +0000 (+0000), MCEUEN, MATT wrote:
OpenStack Infra team,
The OpenStack Infrastructure team hasn't been officially involved in running technical elections for OpenStack for several years now (subject tag removed accordingly). With the advent of Gerrit's REST API, contributor data can be queried and assembled anonymously by anyone. While I happen to be involved in these activities for longer than that's been the case, I'll be answering while wearing my OpenStack Technical Election Official hat throughout the remainder of this reply.
As the Airship project works to finalize our governance and elected positions [1], we need to be ready to hold our first elections. I wanted to reach out and ask for any experience, guidance, materials, or tooling you can share that would help this run correctly and smoothly? This is an area where the Airship team doesn't have much experience so we may not know the right questions to ask.
Aside from a member of the Airship community creating a poll in CIVS [2], is there anything else you would recommend? Is there any additional tooling in place in the OpenStack world? Any potential pitfalls, or other hard-won advice for us?
[...]
As Sean mentioned in his reply, the OpenStack community has been building and improving tooling in the openstack/election Git repository on OpenDev over the past few years. The important bits (in my opinion) center around querying Gerrit for a list of contributors whose changes have merged to sets of official project repositories within a qualifying date range. I've recently been assisting StarlingX's election officials with a similar request, and do have some recommendations.
Probably the best place to start is adding an official structured dataset with your team/project information following the same schema used by OpenStack[0] and now StarlingX[1], then applying a couple of feature patches[2][3] (if they haven't merged by the time you read this) to the openstack/election master branch. After that, you ought to be able to run something along the lines of:
tox -e venv -- owners --after 2018-05-30 --before 2019-05-31 --nonmember --outdir airship-electorate --projects ../../airship/governance/projects.yaml --ref master
(Note that the --after and --before dates work like in Gerrit's query language and carry with them an implied midnight UTC, so one is the actual start date but the other is the day after the end date; "on or after" and "before but not on" is how I refer to them in prose.)
You'll see the resulting airship-electorate directory includes a lot of individual files. There are two basic types: .yaml files which are structured data meant for human auditing as well as scripted analysis, and .txt files which are a strict list of one Gerrit preferred E-mail address per line for each voter (the format expected by the https://civs.cs.cornell.edu/ voting service). It's probably also obvious that there are sets of these named for each team in your governance, as well as a set which start with underscore (_). The former represent contributions to the deliverable repositories of each team, while the latter are produced from an aggregate of all deliverable repositories for all teams (this is what you might use for electing an Airship-wide governing body).
There are a couple of extra underscore files... _duplicate_owners.yaml includes information on deduplicated entries for contributors where the script was able to detect more than one Gerrit account for the same individual, while the _invites.csv file isn't really election-related at all and is what the OSF normally feeds into the automation which sends event discounts to contributors. In case you're curious about the _invites.csv file, the first column is the OSF member ID (if known) or 0 (if no matching membership was found), the second column is the display name from Gerrit, the third column is the preferred E-mail address from Gerrit (this corresponds to the address used for the _electorate.txt file), and any subsequent columns are the extra non-preferred addresses configured in Gerrit for that account.
Please don't hesitate to follow up with any additional questions you might have!
[0] https://opendev.org/openstack/governance/src/branch/master/reference/project... [1] https://opendev.org/starlingx/governance/src/branch/master/reference/tsc/pro... [2] https://review.opendev.org/661647 [3] https://review.opendev.org/661648
Might also be helpful to look at our document that outlines the process we go through[1]. If you have any questions, let us know!
-Kendall (diablo_rojo)
[1] https://opendev.org/openstack/election/src/branch/master/README.rst
On Thu, May 30, 2019 at 3:37 PM Jeremy Stanley fungi@yuggoth.org wrote:
On 2019-05-30 19:04:56 +0000 (+0000), MCEUEN, MATT wrote:
OpenStack Infra team,
The OpenStack Infrastructure team hasn't been officially involved in running technical elections for OpenStack for several years now (subject tag removed accordingly). With the advent of Gerrit's REST API, contributor data can be queried and assembled anonymously by anyone. While I happen to be involved in these activities for longer than that's been the case, I'll be answering while wearing my OpenStack Technical Election Official hat throughout the remainder of this reply.
As the Airship project works to finalize our governance and elected positions [1], we need to be ready to hold our first elections. I wanted to reach out and ask for any experience, guidance, materials, or tooling you can share that would help this run correctly and smoothly? This is an area where the Airship team doesn't have much experience so we may not know the right questions to ask.
Aside from a member of the Airship community creating a poll in CIVS [2], is there anything else you would recommend? Is there any additional tooling in place in the OpenStack world? Any potential pitfalls, or other hard-won advice for us?
[...]
As Sean mentioned in his reply, the OpenStack community has been building and improving tooling in the openstack/election Git repository on OpenDev over the past few years. The important bits (in my opinion) center around querying Gerrit for a list of contributors whose changes have merged to sets of official project repositories within a qualifying date range. I've recently been assisting StarlingX's election officials with a similar request, and do have some recommendations.
Probably the best place to start is adding an official structured dataset with your team/project information following the same schema used by OpenStack[0] and now StarlingX[1], then applying a couple of feature patches[2][3] (if they haven't merged by the time you read this) to the openstack/election master branch. After that, you ought to be able to run something along the lines of:
tox -e venv -- owners --after 2018-05-30 --before 2019-05-31 --nonmember --outdir airship-electorate --projects ../../airship/governance/projects.yaml --ref master(Note that the --after and --before dates work like in Gerrit's query language and carry with them an implied midnight UTC, so one is the actual start date but the other is the day after the end date; "on or after" and "before but not on" is how I refer to them in prose.)
You'll see the resulting airship-electorate directory includes a lot of individual files. There are two basic types: .yaml files which are structured data meant for human auditing as well as scripted analysis, and .txt files which are a strict list of one Gerrit preferred E-mail address per line for each voter (the format expected by the https://civs.cs.cornell.edu/ voting service). It's probably also obvious that there are sets of these named for each team in your governance, as well as a set which start with underscore (_). The former represent contributions to the deliverable repositories of each team, while the latter are produced from an aggregate of all deliverable repositories for all teams (this is what you might use for electing an Airship-wide governing body).
There are a couple of extra underscore files... _duplicate_owners.yaml includes information on deduplicated entries for contributors where the script was able to detect more than one Gerrit account for the same individual, while the _invites.csv file isn't really election-related at all and is what the OSF normally feeds into the automation which sends event discounts to contributors. In case you're curious about the _invites.csv file, the first column is the OSF member ID (if known) or 0 (if no matching membership was found), the second column is the display name from Gerrit, the third column is the preferred E-mail address from Gerrit (this corresponds to the address used for the _electorate.txt file), and any subsequent columns are the extra non-preferred addresses configured in Gerrit for that account.
Please don't hesitate to follow up with any additional questions you might have!
[0] https://opendev.org/openstack/governance/src/branch/master/reference/project... [1] https://opendev.org/starlingx/governance/src/branch/master/reference/tsc/pro... [2] https://review.opendev.org/661647 [3] https://review.opendev.org/661648 -- Jeremy Stanley
Thanks Kendall, Jeremy, Sean – this is very helpful! I think this gives us the tools we need to run a successful election; if we do have any questions I’ll let y’all know.
Appreciate your help, Matt
From: Kendall Nelson kennelson11@gmail.com Sent: Monday, June 3, 2019 8:47 AM To: Jeremy Stanley fungi@yuggoth.org Cc: OpenStack Discuss openstack-discuss@lists.openstack.org Subject: Re: Elections for Airship
Might also be helpful to look at our document that outlines the process we go through[1]. If you have any questions, let us know!
-Kendall (diablo_rojo)
[1] https://opendev.org/openstack/election/src/branch/master/README.rsthttps://urldefense.proofpoint.com/v2/url?u=https-3A__opendev.org_openstack_election_src_branch_master_README.rst&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_C5hC_103uW491yNPPpNmA&m=q-fjV8ndyIv1FhePlotL0hpW_dbr1hG_cxgKFzuTTDw&s=YfQutlHBN5UKc9810nCldR1yNIWDCx3dIFF5qlXVpqU&e=
On Thu, May 30, 2019 at 3:37 PM Jeremy Stanley <fungi@yuggoth.orgmailto:fungi@yuggoth.org> wrote: On 2019-05-30 19:04:56 +0000 (+0000), MCEUEN, MATT wrote:
OpenStack Infra team,
The OpenStack Infrastructure team hasn't been officially involved in running technical elections for OpenStack for several years now (subject tag removed accordingly). With the advent of Gerrit's REST API, contributor data can be queried and assembled anonymously by anyone. While I happen to be involved in these activities for longer than that's been the case, I'll be answering while wearing my OpenStack Technical Election Official hat throughout the remainder of this reply.
As the Airship project works to finalize our governance and elected positions [1], we need to be ready to hold our first elections. I wanted to reach out and ask for any experience, guidance, materials, or tooling you can share that would help this run correctly and smoothly? This is an area where the Airship team doesn't have much experience so we may not know the right questions to ask.
Aside from a member of the Airship community creating a poll in CIVS [2], is there anything else you would recommend? Is there any additional tooling in place in the OpenStack world? Any potential pitfalls, or other hard-won advice for us?
[...]
As Sean mentioned in his reply, the OpenStack community has been building and improving tooling in the openstack/election Git repository on OpenDev over the past few years. The important bits (in my opinion) center around querying Gerrit for a list of contributors whose changes have merged to sets of official project repositories within a qualifying date range. I've recently been assisting StarlingX's election officials with a similar request, and do have some recommendations.
Probably the best place to start is adding an official structured dataset with your team/project information following the same schema used by OpenStack[0] and now StarlingX[1], then applying a couple of feature patches[2][3] (if they haven't merged by the time you read this) to the openstack/election master branch. After that, you ought to be able to run something along the lines of:
tox -e venv -- owners --after 2018-05-30 --before 2019-05-31 --nonmember --outdir airship-electorate --projects ../../airship/governance/projects.yaml --ref master
(Note that the --after and --before dates work like in Gerrit's query language and carry with them an implied midnight UTC, so one is the actual start date but the other is the day after the end date; "on or after" and "before but not on" is how I refer to them in prose.)
You'll see the resulting airship-electorate directory includes a lot of individual files. There are two basic types: .yaml files which are structured data meant for human auditing as well as scripted analysis, and .txt files which are a strict list of one Gerrit preferred E-mail address per line for each voter (the format expected by the https://civs.cs.cornell.edu/https://urldefense.proofpoint.com/v2/url?u=https-3A__civs.cs.cornell.edu_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_C5hC_103uW491yNPPpNmA&m=q-fjV8ndyIv1FhePlotL0hpW_dbr1hG_cxgKFzuTTDw&s=-1ejg3tb3_ttxl-yaOyS6axYA5JmTIQiUrW_H290fSI&e= voting service). It's probably also obvious that there are sets of these named for each team in your governance, as well as a set which start with underscore (_). The former represent contributions to the deliverable repositories of each team, while the latter are produced from an aggregate of all deliverable repositories for all teams (this is what you might use for electing an Airship-wide governing body).
There are a couple of extra underscore files... _duplicate_owners.yaml includes information on deduplicated entries for contributors where the script was able to detect more than one Gerrit account for the same individual, while the _invites.csv file isn't really election-related at all and is what the OSF normally feeds into the automation which sends event discounts to contributors. In case you're curious about the _invites.csv file, the first column is the OSF member ID (if known) or 0 (if no matching membership was found), the second column is the display name from Gerrit, the third column is the preferred E-mail address from Gerrit (this corresponds to the address used for the _electorate.txt file), and any subsequent columns are the extra non-preferred addresses configured in Gerrit for that account.
Please don't hesitate to follow up with any additional questions you might have!
[0] https://opendev.org/openstack/governance/src/branch/master/reference/project...https://urldefense.proofpoint.com/v2/url?u=https-3A__opendev.org_openstack_governance_src_branch_master_reference_projects.yaml&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_C5hC_103uW491yNPPpNmA&m=q-fjV8ndyIv1FhePlotL0hpW_dbr1hG_cxgKFzuTTDw&s=HuMQnPRdsYNWXXTi3Wf1YdH5jm0qBFijcvVNN9kMvvs&e= [1] https://opendev.org/starlingx/governance/src/branch/master/reference/tsc/pro...https://urldefense.proofpoint.com/v2/url?u=https-3A__opendev.org_starlingx_governance_src_branch_master_reference_tsc_projects.yaml&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_C5hC_103uW491yNPPpNmA&m=q-fjV8ndyIv1FhePlotL0hpW_dbr1hG_cxgKFzuTTDw&s=NOM7z42EFjCg1JRSKRwPJuacaAy50VDSBap0gdJ0IMs&e= [2] https://review.opendev.org/661647https://urldefense.proofpoint.com/v2/url?u=https-3A__review.opendev.org_661647&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_C5hC_103uW491yNPPpNmA&m=q-fjV8ndyIv1FhePlotL0hpW_dbr1hG_cxgKFzuTTDw&s=DiP7kRZfGcfnzYvCwBVRcLZyks88kx7Um3WLTuacrPE&e= [3] https://review.opendev.org/661648https://urldefense.proofpoint.com/v2/url?u=https-3A__review.opendev.org_661648&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_C5hC_103uW491yNPPpNmA&m=q-fjV8ndyIv1FhePlotL0hpW_dbr1hG_cxgKFzuTTDw&s=4rKYgxQRHcBvr-wSjHeVSS-rksSlG01XLadWJAT06U8&e= -- Jeremy Stanley
participants (4)
-
Jeremy Stanley
-
Kendall Nelson
-
MCEUEN, MATT
-
Sean McGinnis