For those who won't read the giant wall of text below, a quick summary... If you want to run or vote in upcoming elections for PTL and TC, make sure your Foundation Individual Membership is active and has at least one Email address which matches an Email address in your Gerrit account: log in at https://www.openstack.org/profile/ and check that it says "Current Member Level: Foundation Member" near the top and that at least one of the Primary, Second or Third Email Address fields contains an address which matches at least one of the entries available in the Preferred Email drop-down at https://review.openstack.org/#/settings/contact (case sensitivity doesn't matter but they at least need to be spelled the same).
If you're an "extra-ATC" and don't have a Gerrit account (this is common for translators on the I18n team) then you still need to be a Foundation Member to participate in technical elections and should make sure your member profile includes the Email address listed for you on your team's page at https://governance.openstack.org/tc/reference/projects/ . Now on to the long, boring details for people (like me!) who enjoy reading them; much of this is taken from an Infra specification[1] related to some ongoing work in this area... According to the Bylaws of the OpenStack Foundation Appendix 4 Technical Committee Member Policy[2] (section 3b) along with the OpenStack Technical Committee Charter definitions for APC[3] and ATC[4], we limit the voter rolls for technical elections to Foundation Individual Members. In order to comply with this requirement in prior elections, we required all contributors to CLA-enforced Git repositories to submit contact info to the Gerrit contact store[5] which in turn pinged a simple API in the foundation member system to confirm the preferred Email address in Gerrit matched the primary Email address of an existing OpenStack Foundation Individual Member. This had a number of drawbacks: 1. It forced contributors to join the OpenStack Foundation even if they had no interest in voting or participating in other member benefits. 2. Our interpretation of the meaning of "contributor" for these purposes was unnaturally limited to change owners in Gerrit, in part because commit authors and co-authors weren't constrained by the contact store process and so might not have been members; manual listing as extra ATCs in the governance repo was the sole workaround, and required cumbersome manual verification of foundation membership for each addition. 3. The model was inherently flawed since it's been possible for a couple years now for a member to officially resign or allow their membership to lapse, but contact store submission was only ever enforced once when the account was first set up and so we may have been allowing lapsed or resigned members to vote in technical elections. 4. The implementation was brittle and process confusing, resulting in opaque errors which often confounded new contributors and overall inhibited onboarding. 5. Because the protocol only submitted a single Email address and backend implementation in the member system only queried against a single address field, it forced contributors to use the same primary/preferred address in both systems (at least initially). 6. Gerrit removed contact store functionality[6] upstream after the version we're currently running, and we'd like to be able to upgrade to a newer Gerrit release soon. So what's changing? Very recently the OpenStackID Resources system introduced a member directory API[7] which is public and anonymous. Integrating this into the change owners script[8] we use for generating electoral rolls allows us to expressly filter out non-member contributors. Side effect benefits include: * it will properly limit voting rights for extra ATCs who have not joined the foundation, eliminating any need for the current cumbersome vetting process * it may help further identify duplicate contributors where there exist multiple Email addresses in the member system for a single membership corresponding to multiple accounts in Gerrit with those different addresses * it can even enable us (should we choose) to more easily expand the interpreted definition of ATC/APC to include a variety of other types of verifiable contribution tied to a known Email address including commit authors and co-authors The reasons for this message: 1. Preliminary runs of the patched script suggest that nearly 13% of our active contributors in the last year may not be eligible to vote in or run in upcoming technical elections, so I want to make sure this change doesn't take too many people by surprise. 2. I'd like to assess whether it's reasonable timing to implement this change before the Queens PTL elections, or between the PTL and TC elections, or should wait until after the coming TC election. 3. It would be nice to initiate a debate over ways we can reinterpret the term "contributor" (per drawback #2 above) in the future to more closely match the intent of our bylaws, once we have this initial change behind us. If you've read this far, find me at the PTG or Forum and receive a free Infra team mascot sticker! I have... extras. [1] https://specs.openstack.org/openstack-infra/infra-specs/specs/gerrit-contactstore-removal.html [2] https://www.openstack.org/legal/technical-committee-member-policy/ [3] https://governance.openstack.org/tc/reference/charter.html#voters-for-ptl-seats-apc [4] https://governance.openstack.org/tc/reference/charter.html#voters-for-tc-seats-atc [5] https://review.openstack.org/Documentation/config-contact.html [6] https://gerrit-review.googlesource.com/c/70458 [7] https://git.openstack.org/cgit/openstack-infra/openstackid-resources/tree/app/Models/Foundation/Main/Member.php?id=5b6011d [8] https://review.openstack.org/483974 -- Jeremy Stanley
signature.asc
Description: Digital signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev