persia | clarkb: For clarity, you mean after announcement of end of support? As an example, I believe Ubuntu LTS has examples at both 58 months and 63 months. | 00:29 |
---|---|---|
clarkb | persia: I mean no longer than the upstream support period whatever that may be | 00:30 |
clarkb | fedora's moves around because it is based on getting the n+2 release out for example | 00:30 |
persia | Apologies: I think I failed to ask the question in a way that makes sense. As alternatives I meant "release day + support claim on release day" vs. "release day until EOS day". My first read of your response made me think you might mean the former, but your detail on fedora now makes me think you mean the latter. | 00:32 |
clarkb | ya I think we would support it until the actual EOS day even if that changes from the original plan upstream. Either because next fedora release is slow to go out (which has happened) or ubuntu decides they are done supporting a release early (I don't think this has ever happened) | 00:34 |
*** mriedem has quit IRC | 00:36 | |
*** liujiong has joined #openstack-tc | 00:50 | |
persia | clarkb: Based on last updates shown at old-releases.ubuntu.com, I beleive the last update to 6.06 LTS was 2011-04-21 (58 months). There exists some chance there just weren't any bugs the last couple months, of course :) I don't expect it will happen again, and some releases as the other way (e.g. apparently 66 months for 10.04). | 00:56 |
*** liujiong has quit IRC | 01:08 | |
*** harlowja has quit IRC | 01:10 | |
*** liujiong has joined #openstack-tc | 01:16 | |
*** zaneb has quit IRC | 01:54 | |
*** zaneb has joined #openstack-tc | 01:57 | |
*** rosmaita has quit IRC | 02:49 | |
dhellmann | clarkb : that seems like a detail we should write down somewhere so people aren't surprised, but I don't think the resolution is necessarily the place for it. Maybe as a note in the stable team section of the project team guide? | 03:07 |
*** kumarmn_ has quit IRC | 03:18 | |
*** kumarmn has joined #openstack-tc | 03:30 | |
*** harlowja has joined #openstack-tc | 03:48 | |
*** kumarmn has quit IRC | 04:20 | |
*** kumarmn has joined #openstack-tc | 04:33 | |
*** harlowja has quit IRC | 05:59 | |
*** david-lyle has quit IRC | 06:08 | |
*** cdent has joined #openstack-tc | 08:46 | |
*** jpich has joined #openstack-tc | 08:59 | |
ttx | https://wiki.openstack.org/wiki/Technical_Committee_Tracker just updated | 09:00 |
cdent | good morning tc-members | 09:00 |
ttx | cdent: o/ | 09:00 |
cmurphy | o/ | 09:00 |
ttx | Looks like we are slowly getting closer to resolution on the EM and the interop test location proposals | 09:00 |
* cdent nods | 09:03 | |
EmilienM | hello | 09:03 |
ttx | Doug proposed to track conversation starters at https://etherpad.openstack.org/p/tc-office-hour-conversation-starters | 09:03 |
* johnthetubaguy waves hello | 09:04 | |
cdent | As I understood the idea wasn't to use the etherpad as yet another tracker, but more as a way to list things that maybe we should chat about. | 09:06 |
*** liujiong has quit IRC | 09:07 | |
ttx | Alright then | 09:07 |
ttx | Re: tracking with Storyboard, I plan to create stories for TC $stuff | 09:07 |
ttx | What is the ideal level of granularity ? I was thinking trying to keep it reasonably high-level | 09:08 |
ttx | using https://etherpad.openstack.org/p/PTG-Dublin-TC-topics as a base | 09:09 |
ttx | (and the vision) | 09:09 |
ttx | Maybe I should first list potential stories on an etherpad before creating them, see what that level of granularity would look like | 09:10 |
johnthetubaguy | Where you thinking a story per project, or a task for each project? | 09:10 |
ttx | depends what you mean by project | 09:10 |
johnthetubaguy | yeah, I wasn't sure when I wrote that | 09:11 |
johnthetubaguy | I think I mean per governance project | 09:11 |
ttx | brainstorming at https://etherpad.openstack.org/p/rocky-tc-stories | 09:13 |
johnthetubaguy | ah, now I understand your question better | 09:14 |
cdent | Should we talk today about tony's concerns with the powerstackers group? I feel like I'm missing some critical info. | 09:16 |
cdent | https://review.openstack.org/#/c/551413/ | 09:17 |
ttx | cdent: happy to | 09:17 |
johnthetubaguy | ah, so vendors already have Power KVM products, which are different to PowerVM products? | 09:18 |
ttx | This team is working on PowerVM support | 09:22 |
ttx | We suggested that its scope should be on all Power, since "PowerStackers" sounds so much better | 09:22 |
ttx | BUT that failed to take into account that some other people are working on POWER arch support | 09:23 |
ttx | and those are not really in the Power[VM]Stackers team | 09:23 |
ttx | At this point it's probably just simpler to align the mission/name with the current team scope | 09:23 |
ttx | It's a cheap rename anyway | 09:24 |
cdent | That doesn't seem like it is really addressing tony's concerns which is that we have groups that cluster around brands rather than projects. (At least it seems like that's what he's saying. I'm not certain) | 09:25 |
ttx | cdent: I think renaming the team and rewording te scope would address Tony's concerns. That is what he proposed after all | 09:27 |
cdent | Right, it is his proposal but he admits in his response to me that it is a compromise | 09:28 |
cdent | and it may be a fine compromise | 09:28 |
ttx | It moves from clustering around a brand (Power*) to clustering around a technology (PowerVM), which is probably better | 09:29 |
ttx | At one point I was wondering if those (WinStackers or Power[VM]STackers would not be better set up as SIGs | 09:30 |
ttx | since they could also band more directly with their users | 09:30 |
cdent | But there are two types of groupings: topical (nova, ceilometer, etc), branding (power, etc) | 09:30 |
ttx | agree that the verticals conflict a bit with the Guild set up | 09:30 |
cdent | I personally think (I've just read the great virt drive split thread from 2014) that grouping by brand could have some advantages | 09:31 |
ttx | PowerVM and Winstackers (or VMWareStackers if that is ever proposed) are really transversal guilds | 09:31 |
ttx | Would actually make a lot of sense as SIGs | 09:31 |
cmurphy | that does seem to fit a little better | 09:32 |
ttx | they still own repos, but I think it's ok as long as those are... peripheral/optional repos | 09:33 |
ttx | Like the Security SIG maintaining bandit | 09:34 |
ttx | or winstackers maintaining Hyper-V support plugins | 09:34 |
ttx | Winstackers was actually next in my long list of SIG candidates | 09:34 |
ttx | But I was OK with PowerStackers being set up as a team first, and then convert both to SIGS :) | 09:35 |
ttx | since conversion takes some amount of convincing | 09:36 |
* ttx looks for other guild-like topic-driven or brand-driven or tech-driven project teams | 09:36 | |
ttx | Security was already converted... | 09:37 |
ttx | I could see Rally turn into a Performance SIG, but it makes sense as a project team as well | 09:38 |
ttx | (as long as it keeps its Rally-centric scope) | 09:38 |
ttx | so yes, WinStackers / PowerStackers are the outliers in the current project team list | 09:39 |
cmurphy | rally as a SIG doesn't seem right to me, that seems like leading down a road where all horizontal projects become SIGs | 09:39 |
ttx | If InteropWG turns into a SIG I would just fold RefStack under it | 09:40 |
ttx | since it's really a tool for the WG, not part of the openstack deliverables | 09:40 |
ttx | cmurphy: yeah... | 09:40 |
ttx | cmurphy: I think it has SIG potential when it's both an upstream and ddownstream concern | 09:41 |
ttx | so QA or release management are very upstream, would stay as project teams | 09:42 |
ttx | Security on the other hand is much better as a SIG, since expertise is all over | 09:42 |
cdent | ttx: Is "degree of upstream" the right heuristic? I always thought it was breadth of potential participants | 09:43 |
ttx | Performance, or Documentation... it's a bit more fuzzy I guess | 09:43 |
cmurphy | that's a really difficult line to draw | 09:43 |
ttx | cdent: breadth of potential participants is a much better way to describe it | 09:43 |
cdent | SIGness was supposed to be a way to get different people in the same room | 09:43 |
cdent | "room" | 09:43 |
ttx | that is what I actually meant :) | 09:43 |
cdent | :) | 09:43 |
* cdent contacts the ministry of information | 09:44 | |
ttx | cmurphy: yeah, opens up the Pandora box a bit, which is why I haven't been pushing too hard to convert WinStackers to a SIG yet | 09:44 |
ttx | But I feel like that group would be a lot more relevant if it as the OpenStack-on-Windows group rather than the maintainers of the hyperv plugin | 09:45 |
ttx | Ideally the ask should come from them | 09:45 |
cmurphy | winstackers fits as a SIG in my mind because it really is "special interest", it's a bit niche | 09:46 |
ttx | cmurphy: yes, you either care or you don't | 09:46 |
cmurphy | a performance SIG doesn't make sense to me becaue everyone should be at least somewhat concerns about performance | 09:46 |
cmurphy | concerned* | 09:46 |
ttx | that's a good way of looking at it yes | 09:46 |
cdent | general interest instead of special interest? | 09:47 |
ttx | hmm, not really, but the idea that perforamce should be everyon's concern rather than just a specific team's | 09:47 |
cdent | I was kidding | 09:47 |
cdent | I do, however, want to be sure that we don't wield SIGs as a multi-tool/cureall kind of thing | 09:51 |
cmurphy | ++ | 09:51 |
ttx | It's not really a question of whether the topic is important for everyone or not... It's more a question of how specific is the group working on it. Does it take a special kind of person. As much as I think that everyone should care about security, I realize it takes a specific mindset | 09:51 |
ttx | cdent: agreed, we just added that new construct and need to check that everything that was supposed to benefit from transitioning to it already moved | 09:52 |
ttx | or decided to keep using the construct they prefered | 09:53 |
ttx | The main issue with SIGs at this point is communications, due to the silly split of MLs | 09:53 |
ttx | but that's not really a SIG-specific issue, just hinders their progress | 09:54 |
ttx | as it hinders all dev/ops artifical barrier reduction efforts | 09:55 |
johnthetubaguy | I think I had always made the distinction more on deliverables, do they deliver python code, but that seems incorrect... | 09:56 |
ttx | johnthetubaguy: SIGs can own repos and produce code, but in vase of code that would be more support/optional code | 09:57 |
ttx | case* | 09:57 |
ttx | since the production of "OpenStack" is under the TC's responsbility, and uses the Project Team structure | 09:57 |
cdent | I think we've got at least three interpretations, which is both not suprising also propbably fine | 09:57 |
johnthetubaguy | ttx: Right, that seems to put winstackers and power(vm)stackers in governance, I think | 09:58 |
cdent | yes | 09:58 |
ttx | It's one thing to have a Security SIG maintaining bandit. It's another to have a WinStackers SIG producing nova-hyperv | 09:58 |
*** dtantsur|afk is now known as dtantsur | 09:59 | |
johnthetubaguy | or os.win or whatever it is | 09:59 |
johnthetubaguy | yeah | 09:59 |
johnthetubaguy | so I think this makes me +2 on tonyb's patch... is that where other folks are thinking? | 10:00 |
ttx | I agree that's pushing it a bit too far, which is why despite WinStackers's guild-like / brand-centric approach I refrained from suggesting that they transition to SIG yet | 10:00 |
ttx | johnthetubaguy: I'm fine with it as well | 10:00 |
cdent | I'm neutral, but I'm not really sure why I feel that way. | 10:03 |
cdent | proabably because matthew is neutral | 10:04 |
cmurphy | whether or not this group moves to a SIG, the complaint about its name and declared scope is valid | 10:04 |
cmurphy | it's not inclusive of existing work that it claims to include | 10:05 |
johnthetubaguy | I am leaning on the side of correctly representing the reality of the group | 10:06 |
cdent | so we got in this state because we wanted to _permit_ the group to be inclusive of more stuff | 10:06 |
cdent | and now we're saying "it's not already in there, so the name is no good" | 10:07 |
johnthetubaguy | the Power KVM folks have little overlap with the Power VM folks, in code and group make up. Asking them to join forces doesn't seem to help anyone at this point, or am I missing someone? | 10:07 |
cdent | If that's true, then yeah, a rename is right, but we should try to learn our lesson (whatever it is) from this quick turnaround. | 10:08 |
johnthetubaguy | I totally forgot about that distinction, I always forget how many options there are with Power | 10:22 |
ttx | smcginnis: do you have anyone who stepped up to fill the "Designate contributors" help-most-needed item that the Foundation should send a thank-you letter to ? (asking you since you are the TC sponsor for that item) | 10:48 |
ttx | flaper87: do you have anyone who stepped up to fill the "Glance contributors" help-most-needed item that the Foundation should send a thank-you letter to ? (asking you since you are the TC sponsor for that item) | 10:48 |
smcginnis | ttx: No, I never had anyone that contacted me about designate. | 10:51 |
flaper87 | ttx: yeah, smcginnis did :D | 10:53 |
smcginnis | ;) | 10:53 |
flaper87 | and, TBH, the entire glance community became more active | 10:54 |
flaper87 | the few there are | 10:54 |
smcginnis | That's true. It's a small team, but it really seems like they've been able to pick things up again. | 10:54 |
ttx | ok, so nobody in particular. Thanks! | 11:07 |
*** kumarmn has quit IRC | 12:47 | |
*** mriedem has joined #openstack-tc | 12:51 | |
*** rosmaita has joined #openstack-tc | 12:57 | |
fungi | clarkb: what we had suggested about stable support timeframes is that it's highly unlikely infra will commit to building/running images for distro releases which fall out of (distro upstream) maintenance | 12:58 |
fungi | _however_ | 12:58 |
fungi | if there are people interested in those ancient branches, that means they in theory have some supported platform they're interested in continuing to run them on | 12:59 |
fungi | so it's up to them to work with infra to get images building for those platforms if they want them to continue to be tested in our ci system | 12:59 |
fungi | they might also opt for running third-party ci systems reporting on changes for the respective extended maintenance branches if that makes sense | 13:00 |
*** kumarmn has joined #openstack-tc | 13:04 | |
cmurphy | that made a little more sense when the proposal involved an explicit handoff | 13:05 |
mugsie | ttx: I have a few people that came to me and stepped up for Designate, I can send on a list and what they did | 13:07 |
ttx | mugsie: that would do it, yes. thanks! | 13:09 |
smcginnis | Would be good to recongnize responses to that "most wanted" list to try to encourage more. | 13:10 |
dmsimard | fungi: It probably becomes a bit sensitive to have first party "support" for upstream unmaintained distribution images. Even if someone maintains it... If we host it, we're probably the ones on the hook and liable for issues/security. | 13:12 |
fungi | dmsimard: yep, which is why we would only want to do that for distro versions which are actually being maintained, just acknowledging they may not be the same distros we started testing those releases on in the beginning | 13:14 |
dmsimard | fair | 13:14 |
dhellmann | ttx, cdent : the idea with the etherpad was that not every "conversation starter" is necessarily a "task" to be completed or tracked | 13:28 |
*** Ryushin7BX8NR has joined #openstack-tc | 13:32 | |
zaneb | I've been thinking a bit about the project vs. SIG question in the context of the Kingbird thread... | 13:33 |
zaneb | it seems to me that successful projects are defined by their solution-space | 13:34 |
zaneb | if you have a group that's defined by the problem-space, then you should be asking why it's not a SIG instead of a project | 13:34 |
*** Ryushin7BX8NR has quit IRC | 13:35 | |
cdent | that's potentially useful | 13:37 |
cmurphy | what's the difference between a problem space and a solution space? those seem like two sides of the same coin to me | 13:39 |
cmurphy | i'm trying to form an articulate question about the difference and i can't even form it without the phrase "solving a problem" | 13:40 |
*** jroll has quit IRC | 13:41 | |
*** jroll has joined #openstack-tc | 13:42 | |
*** dtantsur is now known as dtantsur|brb | 13:45 | |
dtroyer | cmurphy: I see it as solutions can fix more than one problem, problems may have more than one solution. Scope depends on which one you pick | 13:45 |
dims | hey y'all | 13:49 |
*** nzfrenetically has joined #openstack-tc | 13:50 | |
smcginnis | Morning dims. Snowed in yet? | 13:50 |
dims | smcginnis : 4 inches or so as of now. possibly 12-16 by the time it wraps up this evening | 13:52 |
smcginnis | dims: Sounds like a snow day for the kids. ;) | 13:53 |
dims | y the teenager is not even awake yet :) | 13:54 |
smcginnis | Hah! | 13:54 |
*** nzfrenetically has quit IRC | 13:55 | |
zaneb | cmurphy: e.g. in the context of Kingbird, their problem-space is "multi-region". but there isn't a coherent solution to 'fix' multi-region, it's a bit of work on a lot of different solutions (images in multiple regions, keypairs in multiple regions, &c.). IMHO it's a mistake to try to form a _project_ around that | 14:02 |
cmurphy | zaneb: what about winstackers? is their problem-space OpenStack on hyperv or is their solution-space the hyperv-related deliverables they produce? | 14:05 |
zaneb | I don't know because I really don't care about hyperv ;) | 14:07 |
zaneb | but I'd say that if they have one deliverable, or related set of deliverables, (e.g. a hyper-v driver for Nova) then it's a project | 14:08 |
zaneb | if it's about making every user interaction in OpenStack hyperv-friendly (I don't think it's about that) then it's a SIG, because you can't fix every project in OpenStack by starting your own project to compete with bits of all of them | 14:10 |
fungi | granted, that's what we told the tricircle team, which is why they split off kingbird (unless i'm misremembering the history there) | 14:17 |
*** dtantsur|brb is now known as dtantsur | 14:24 | |
*** hongbin has joined #openstack-tc | 14:31 | |
openstackgerrit | Jeffrey Zhang proposed openstack/governance master: Move kolla-kubernete project under governance of openstack tc https://review.openstack.org/552531 | 14:33 |
*** annabelleB has joined #openstack-tc | 14:40 | |
clarkb | fungi: ya its fine if they want to migrate onto some supported platform they are interested in keeping going. Just want to make it clear we likely won't run unsupported releases even if that is the desire (and I expect that there will be a non zero desire for that just based on knowing what random people run in production) | 14:49 |
fungi | clarkb: i fully agree we should make that clear. maybe https://docs.openstack.org/infra/manual/testing.html is begging for a new section about images? | 14:58 |
clarkb | ya that likely is the best location for this info | 14:59 |
fungi | dmsimard: ^ maybe you're interested in trying to draft that? | 15:08 |
dmsimard | sure | 15:09 |
fungi | thanks! | 15:14 |
*** david-lyle has joined #openstack-tc | 15:25 | |
*** harlowja has joined #openstack-tc | 15:46 | |
*** david-lyle has quit IRC | 15:57 | |
*** dklyle has joined #openstack-tc | 15:57 | |
*** harlowja has quit IRC | 16:06 | |
*** dtantsur is now known as dtantsur|afk | 17:18 | |
openstackgerrit | James E. Blair proposed openstack/governance master: Remove Zuul from OpenStack governance https://review.openstack.org/552637 | 17:22 |
cdent | that causes me to have a sad and a happy at the same time | 17:25 |
smcginnis | I was thinking the same thing. | 17:28 |
smcginnis | Kind of like a kid growing up and moving off to college? | 17:29 |
cdent | yeah | 17:30 |
dims | awwwww | 17:53 |
fungi | except it got a scholarship so we don't need to worry about coming up with tuition | 17:59 |
fungi | just beer money | 17:59 |
cdent | woot | 18:00 |
*** jpich has quit IRC | 18:07 | |
dmsimard | Are "top-level projects under the OpenStack Foundation" documented somewhere ? Mostly curious. | 18:10 |
cdent | dmsimard: I believe they are supposed to be responsible for that themselves. I'm not aware of a unified view. ttx probably has more accuate info. | 18:12 |
dmsimard | cdent: I guess my question is about the "split" between openstack projects, openstack foundation projects and then projects that are not in either but still hosted by the foundation (don't want to spark a stackforge debate) | 18:14 |
dmsimard | So I guess this would be the foundation's third project ? Between OpenStack, Kata and Zuul. | 18:14 |
fungi | yeah, not counting the edge computing strategic focus area which last i heard still has no code projects, only working groups | 18:14 |
dmsimard | OpenStack has it's projects, Kata has it's own and then Zuul has others. | 18:15 |
cdent | yes, but at the foundation layer they are something like strategic areas: edge, infra, ci/cd, containers | 18:15 |
clarkb | cdent: ya that | 18:15 |
dmsimard | ah, interesting | 18:15 |
fungi | i expect zuul will likely copy the formatting of openstack's governance model for tracking repositories, mainly so that they can identify our constituent electorate and be able to reuse some of the election tooling we've developed in openstack | 18:17 |
dmsimard | So then, theoretically speaking, a new project could be "hosted" (or "governed") by any of these top level projects | 18:17 |
fungi | right | 18:17 |
fungi | it's unknown at present whether there will be a unified project governance across all projects in a given strategic focus area, or multiples in parallel | 18:18 |
cdent | dmsimard: yeah, that's one of the topics we didnt quite reach at the PTG: how, when someone applies to be an official openstack project do we guide them to a foundation friend if that makes better sense | 18:18 |
fungi | right now the only mature example we have for precedent is openstack, which is the only project within the open infrastructure strategic focus area | 18:18 |
fungi | all of this is at such an early stage i think we're all afraid to smother it in too much policy and process but rather allow it to evolve a bit more organically until we see the problems/roadblocks which demand more structure | 18:19 |
cdent | +1 | 18:20 |
clarkb | also worth noting I don't think there is a stackforge debate. As of today if you aren't an openstack project but are hosted by infra you are part of stackforge iirc | 18:20 |
fungi | defining too much structure up front could result in steering these projects in the direction we predict they would go rather than in the direction which is actually best for them | 18:21 |
dmsimard | clarkb: Yeah, that's where I was getting at by talking about "openstack, kata, zuul ... and then the 'others'". I'm trying to stay up to date on these kind of changes so I'm not surprised by something I didn't see coming for ara ;) | 18:21 |
fungi | my only debate wrt "stackforge" is that i'd like to not reuse that name, since it already has baggage/connotation for a lot of people | 18:22 |
smcginnis | I think it's a very good idea not to impose unnecessary structure or process, at least at this point. | 18:22 |
dmsimard | +1 | 18:22 |
clarkb | dmsimard: ya and kata largely isn't hosted by infra (we host their mailing lists, that is it) | 18:22 |
fungi | i think we've sufficiently burned the name "stackforge" such that people will make (likely somewhat incorrect) assumptions about what we're talking about if we call something "stackforge" | 18:22 |
smcginnis | It would be interesting to have some sort of high level Foundation view though that shows all the things under its governance. | 18:22 |
smcginnis | If for no other reason that curiosity. | 18:23 |
clarkb | dmsimard: so that is decoupled from infra even further | 18:23 |
dmsimard | Imposing anything is never fun for anyone anyway. We can suggest things like we did to Kata for their CI and infrastructure, for example, that's totally fine. | 18:23 |
smcginnis | We stored the "stackforge" bits somewhere in the big tent, right? :) | 18:23 |
dmsimard | smcginnis: The linux foundation has such a list: https://www.linuxfoundation.org/projects/ | 18:23 |
fungi | i like being able to come to new projects and say "here's a menu of really amazing resources you can choose from if you want, no hurry, you can always decide later that you want to start using something too" | 18:24 |
smcginnis | dmsimard: Yeah, something like that would be nice. | 18:24 |
smcginnis | Always good to have a nice pretty page of logos. | 18:24 |
fungi | i find that lf logo wall pretty useless | 18:25 |
dmsimard | smcginnis: the openstack foundation has a pretty page of logos, it's here :p https://www.openstack.org/foundation/companies/ | 18:25 |
fungi | but i suppose some people relate to it | 18:25 |
cdent | On a page like that (of project), we'd have just the OpenStack O, none of the internal project logos, right? (I hope) | 18:25 |
fungi | yeah, our companies page is more about providing a place for member companies and donors to be able to point and say "see, we're helping!" | 18:25 |
smcginnis | cdent: That's what I would think. Just top level. | 18:26 |
smcginnis | The "O" could link to our little menagerie on another page. | 18:26 |
dmsimard | fungi: the project list is kind of the same thing, "look, I'm a X foundation project!" | 18:26 |
cdent | yes please | 18:26 |
fungi | the lf page is definitely "let's see how impressive a logo count we can make this" (no cncf logo, but there's logs for each of the subprojects under the cncf) | 18:27 |
fungi | no, wait, it's worse than that | 18:28 |
fungi | a logo for the cncf _and_ logos for all the projects under the cncf | 18:28 |
fungi | so i really don't feel that page usefully documents anything | 18:29 |
persia | It is a measure of success problem. If an organisation has a business model where "success" includes having many well-funded projects, having a project-based logo wall that shows that a given community looking for a legal entity would be in good company to join is useful. | 18:36 |
persia | If an organisation has a business model where "success" includes ensuring that members have a neutral collaboration environment, or members have access to world class infrastructure, or something similar, such a page is less valuable. | 18:37 |
persia | (and re: cfcf+cfcf "projects": technically, "cncf" itself is defined as an LF project (with appropriate management, controls, etc.), but that project happens to include a facility to initiate projects (unlike most LF projects).) | 18:38 |
persia | Oh, and if an organisation has a business model dependent on donated funding, hardware, staff, etc., then "success" is usually driven by ensuring donors are well-credited, making it very important to have segmented logo pages for different classes and types of donation. | 18:40 |
pabelanger | I'm preparing the Condorcet voting for the S release poll, and curious if there is a list of flags I should enable for the poll? | 19:35 |
pabelanger | or are the defaults (for public) enough | 19:35 |
pabelanger | fungi: mordred: ^ | 19:35 |
fungi | pabelanger: you can always try a draft one and try it out from a few machines or something | 19:37 |
pabelanger | fungi: yah, that is the current plan now | 19:38 |
pabelanger | okay, so it seems voting results are live, after votes have been casted now with public | 19:43 |
pabelanger | not after poll has been closed | 19:43 |
smcginnis | Hmm, is that maybe another option? I kind of like not having influenced votes. | 19:46 |
pabelanger | smcginnis: yah, we can only expose results to specific email addresses | 19:47 |
pabelanger | if we do that, there is no public record to users and we rely on officials to say what the results are | 19:47 |
*** annabelleB has quit IRC | 19:51 | |
openstackgerrit | Kiran Thyagaraja proposed openstack/governance master: Add ansible-role-k8s-rabbitmq https://review.openstack.org/552673 | 19:53 |
*** annabelleB has joined #openstack-tc | 20:01 | |
pabelanger | okay, seems public results while poll is open, likely fits with the idea of public voting | 20:11 |
pabelanger | so, I'll keep working on that assumption for now | 20:11 |
*** annabelleB has quit IRC | 20:16 | |
*** annabelleB has joined #openstack-tc | 20:16 | |
*** annabelleB has quit IRC | 20:26 | |
*** harlowja has joined #openstack-tc | 20:37 | |
fungi | there's no option to only make results public after the poll closes? that's what we do with the non-open polling for elections | 20:39 |
fungi | hrm, seems there is no explicit option for it, so must be the default behavior (maybe only for private polls?) | 20:42 |
pabelanger | fungi: yah, no option. And think is the default behavior of private | 20:43 |
fungi | strange | 20:43 |
fungi | unfortunately having the results updated in real time while the poll is still open raises the risk of stuffing, as smcginnis suggests | 20:44 |
*** cdent has quit IRC | 20:44 | |
smcginnis | I think I would rather keep it private if we have to make that trade off. | 20:44 |
pabelanger | I don't think I have all the bits in place to work with a private poll in the next ~3hours | 20:46 |
pabelanger | I'd need a list all our email addresses | 20:46 |
pabelanger | and would likely need to confirm with mordred on what sort of split was used in the past | 20:47 |
pabelanger | we could say results are limited to a single email address, then after the poll closes make the unique URL to view results public | 20:48 |
pabelanger | I did confirm I got a separate email with URL to voting results | 20:48 |
diablo_rojo | pabelanger, when we do the ptl and tc elections we only enable detailed ballot reporting | 20:50 |
pabelanger | diablo_rojo: k, let me try that setting. I didn't toggle that one yet | 20:51 |
diablo_rojo | pabelanger, but dont toggle the next radio box that appears below that unless you want to show in the results who voted for what | 20:53 |
pabelanger | no luck, results still public before poll closes | 20:53 |
pabelanger | yah, I only selected top level option | 20:54 |
diablo_rojo | pabelanger, we have the electorate generated for the ptl elections if you want that to use for the private poll | 20:56 |
diablo_rojo | the actual generation of the rolls takes a long time, but I still have the files from the most recent election | 20:56 |
pabelanger | diablo_rojo: yah, I believe part of the reason for trying public polling this time around, was the list of email address was so large, it took a week to just to email everybody their private URL. But, I am unsure if mordred was aware that results of a public poll could be viewed before it was closed | 20:59 |
pabelanger | so, I'm a bit conflicted how to proceed ATM | 20:59 |
diablo_rojo | pabelanger, ah got it. I know CIVS has a max number of people you can add at a time, but I don't think its ever taken a week to add the electorate for the TC elections (which I suspect is the same as that for release naming? ) | 21:00 |
pabelanger | diablo_rojo: I'd have to defer to mordred. But would think TC and release naming used the same source for emails | 21:01 |
smcginnis | I guess if it's between hiding the real time results and getting the voting out there and a name chosen, for now I would choose the public poll and we can evaluate afterwards how it went and if we think it caused issues and needs to be changed for T. | 21:02 |
clarkb | release naming was open to all foundation members iirc | 21:02 |
clarkb | not just TC electorate | 21:02 |
smcginnis | ++ | 21:02 |
pabelanger | smcginnis: yah, that is my feeling too | 21:03 |
zaneb | pabelanger: there's no way to vote 'strategically' in a condorcet poll, so I don't think it's a big problem that you can see results. I guess in the worst case it might encourage more people to try voting multiple times? | 21:04 |
smcginnis | I was thinking of cases where I prefere name A more than name B, but I go to vote and see B is leading so I get discouraged and think there's no way A will win so I might as well vote B too. | 21:05 |
*** annabelleB has joined #openstack-tc | 21:16 | |
pabelanger | zaneb: sure, but if feel in a public poll, if results were private or public, that wouldn't deter somebody from voting multiple times. | 21:16 |
fungi | pabelanger: consider testing the private results option. i expect it's just going to e-mail you a url to the results, which you can then publish to the ml | 21:28 |
fungi | wouldn't be much different than what we do for elections | 21:29 |
fungi | the only difference is that with elections and a private poll, casting a ballor tells you where the results url will appear once the poll is closed | 21:29 |
pabelanger | fungi: yah, that is right. I get a dedicated URL to view results. Would can then be shared with people via ML. So, that is also an option. I just means a 2nd URL people need to use to view the results over just a single once the poll closes. | 21:50 |
*** mriedem has quit IRC | 21:55 | |
*** kumarmn has quit IRC | 22:02 | |
*** kumarmn has joined #openstack-tc | 22:20 | |
*** kumarmn has quit IRC | 22:25 | |
fungi | well, even with our normal elections there are separate ballot and results urls (by necessity) | 22:35 |
*** kumarmn has joined #openstack-tc | 22:37 | |
*** Guest78602 is now known as amrith | 22:52 | |
*** kumarmn has quit IRC | 22:58 | |
*** hongbin has quit IRC | 22:59 | |
*** kumarmn has joined #openstack-tc | 23:07 | |
*** kumarmn has quit IRC | 23:11 | |
*** kumarmn has joined #openstack-tc | 23:15 | |
*** kumarmn has quit IRC | 23:20 | |
pabelanger | fungi: okay, I'll proceed with results only viewable with my email address, then post the URL to public ML with results | 23:32 |
fungi | that seems sane | 23:32 |
*** mriedem has joined #openstack-tc | 23:56 | |
*** dklyle has quit IRC | 23:57 | |
pabelanger | and voting URL sent to MLs | 23:59 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!