| slaweq | election season email sent | 07:03 |
|---|---|---|
| slaweq | I have also tasks in my calendar to send another emails next week | 07:03 |
| slaweq | I was also wondering if we maybe should send direct message to the existing PTL's as well, maybe now and e.g. in the middle of the nomination window, just to make sure they are aware that it is again this time of the year. I can handle that if needed but wanted to know first what do you think about this idea | 07:05 |
| fungi | the only reason i can think of (other than if there's nobody with time to do it) is that it could set a precedent leading some ptls to expect personal election reminders for future elections and making them less inclined to pay attention to similar announcements on the mailing list | 12:17 |
| fungi | but election officials have done similar direct outreach in the distant past, so this wouldn't be the first time anyway | 12:18 |
| frickler | one could also argue that this special treatment would give current PTLs an (possibly unfair) advantage over other candidates, so IMO the general mail to the list is and should be sufficient | 12:27 |
| frickler | another thing to consider is whether such an unsolicited email might be considered spam | 12:30 |
| frickler | if not, sending mail to all contributors that were active during the current cycle does sound like a possible alternative instead? the delta in numbers shouldn't be too big anymore these days | 12:30 |
| slaweq | frickler it could be theoretically treated as giving adventage for current PTLs but practically what we have seen in last few years is that there are PTLs who are missing message in the ML and forget to send their nomination and project has no candidates finally at all. I was thinking about trying to minimize this kind of issue this time maybe. But I got Your point that this could be not fair for some. | 13:45 |
| slaweq | Sending it to all contributors of the project may be more work as I wanted simply to try to get email of current PTL from the projects.yaml file and send mail to those addresses only | 13:45 |
| slaweq | for other contributors I would need to search in git log | 13:46 |
| slaweq | not big issue I guess but a bit more work probably | 13:46 |
| fungi | technically there's no need to search git logs, the election tooling will generate lists of contributor e-mail addresses for each project since that's the input to the voting system for distributing ballots anyway | 13:47 |
| slaweq | fungi ahh, right, this is something new for me still as I never worked close with election process :) | 13:49 |
| slaweq | so yes, I can try to think about something like that | 13:49 |
| fungi | tox -e venv -- owners -a <after date> -b <before date> -o <output dir> -r <governance ref/tag> | 13:50 |
| fungi | or just `tox -e venv -- owners --help` to see all the options | 13:50 |
| fungi | most of the options to the owners tool also have sensible defaults like -b uses todays date, -r uses the tip of the governance repo's master branch, et cetera | 13:51 |
| fungi | i use it as a sort of swiss army knife for getting lists of contributor details to do things like demographic breakdowns around release time | 13:53 |
| slaweq | fungi thx a lot | 14:02 |
| ianychoi | Hi slaweq, I have created Etherpad for the election season: https://etherpad.opendev.org/p/TC_PTL_Elections2025.1Epoxy - any chance for you to review it, and would you please double-check / comment your time zone and availability? | 16:47 |
| JayF | I think there's value generally in us looking at the TC diversity numbers as people self-nominate, just to try and head off any issues with extra encouragement. I know in the past someone doing that led to me running for the TC. | 16:53 |
| JayF | I'm also around and generally available to help; although this week and next my time is pretty limited. | 16:53 |
| fungi | encouragement of two kinds: encouraging additional people with varied affiliations to run for a seat, and also reminding candidates with a shared affiliation to confer with one another | 16:58 |
| JayF | yes-ish, although I have heard people say they don't intend to do the latter no matter what | 16:59 |
| ianychoi | Thank you JayF - just for election process perspective I think checking during TC Campaigning period once TC nomination ends will be great. | 17:00 |
| fungi | though if nobody checks before the nomination period ends, then it's too late to convince anyone else to run | 17:00 |
| JayF | We should also check like halfway through TC nominations period; so that we can encourage people to run if we don't have enough candidates | 17:01 |
| fungi | but also, it shouldn't (just, or at all) be on the election officials to do that, anyone in the community can and ideally should | 17:01 |
| fungi | when i was an election official i tended to avoid directly involving myself in encouraging or discouraging anyone, in order to maintain impartiality, but that may have been overly-cautious on my part | 17:02 |
| ianychoi | For the previous election, some nominations use personal e-mail addresses, which were difficult to identify affiliations as election official | 17:02 |
| fungi | ianychoi: yeah, that's where affiliation queries to the foundation member database come in handy | 17:03 |
| fungi | similar to what i've got in that https://review.opendev.org/876738 poc | 17:04 |
| fungi | i think if we refine that we could also integrate it into the candidacy check output | 17:05 |
| ianychoi | Aha great idea | 17:07 |
| fungi | not fully sure what the implementation should look like, should probably at most be comments/annotations in the generated rst which are omitted in the html rendering, so that we don't make it look like candidates officially represent their employers | 17:07 |
| fungi | 876738 is more about post-election demographics (foundation staff often ask me for things like a list of all community leadership positions held by contributors with a particular affiliation), but the election tooling already has examples of affiliation lookups since we report that in the full structured data for the electorate. 876738 does include the minor addition of a fallback to | 17:10 |
| fungi | checking one extra potential affiliation data source, and i could split that out into its own patch if preferred | 17:10 |
| ianychoi | Right now, I don't want to see affiliations on generated HTML outputs. I was anticipating seeing via candidacy check output or via executing command like 'tox -evenv -- check-affiliations --election tc' when I am reading the patch | 17:13 |
| fungi | right, i was saying i definitely think we should not put affiliation data in the generated html. adding the output to ci-check-all-candidate-files would be pretty simple and then it would also appear in the zuul job logs too | 17:19 |
| fungi | but having a separate check-affiliations or similar would be pretty easy to add too | 17:20 |
| * gouthamr is catching up to this election discussion | 17:48 | |
| gouthamr | we're light on the agenda at the TC meeting today - this would be a good open discussion topic | 17:48 |
| opendevreview | Merged openstack/election master: [templates] Update links https://review.opendev.org/c/openstack/election/+/911387 | 17:50 |
| gouthamr | slaweq++ ty kicking off things; and ianychoi: ty for the etherpad.. i'm not an election official :) but, like others here, i'm not a candidate either; so i'll watch things from the sidelines and help you two out | 17:50 |
| slaweq | ianychoi thx for the etherpad, I just updated my availability there, basically I will be on PTO next week so my availability will be limited but after Aug 17th I will be back and I will be available generally | 18:08 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!