| 15:24 | <bradleymeck> | have we had a "vote" in recent memory on a proposal? |
| 15:24 | <bradleymeck> | do we even have a process? |
| 15:32 | <shu> | ecma does |
| 15:33 | <shu> | tc39 itself in general is allergic to voting |
| 15:33 | <shu> | i also cannot recall where we actually voted on proposal advancement |
| 15:35 | <bradleymeck> | shu: that is why I ask |
| 15:36 | <bradleymeck> | I'm interested in taking up Collection normalization again, but not if I can't call a vote if we get stuck on naming again |
| 16:14 | <shu> | my understanding of "can't" has always been social pressures and political capital cost |
| 16:14 | <shu> | so you _can_, if that's the cost you're willing to bear |
| 16:15 | <bradleymeck> | it was a pure block, no discussion last time |
| 16:15 | <bradleymeck> | the statement was that I could change the name to what Waldemar wanted or I could not advance I even gave a presentation on why we shouldn't change that name |
| 16:16 | <bradleymeck> | so... need to be able to call a vote if we cannot even discuss it |
| 16:49 | <ljharb> | bradleymeck: i talked to waldemar after that, and we came up with a compromise that you rejected, iirc |
| 16:50 | <bradleymeck> | ljharb: the double property/reject if both form doesn't work since the argument was about reusability and reusing a Map would always reject |
| 16:50 | <ljharb> | that was only for Set |
| 16:50 | <bradleymeck> | the problem is people treating these things as if they can be passed between the 2 Set/Map types |
| 16:51 | <ljharb> | yes, that is where waldemar's objection came from |
| 16:51 | <bradleymeck> | which somehow naming the set property to keys() satisfies but not values() |
| 16:51 | <ljharb> | but just like anything else in committee, delegates' concerns are all valid even if you don't agree with them |
| 16:51 | <bradleymeck> | which is why I gave a presentation on why to use values() |
| 16:51 | <ljharb> | sure, and i happen to agree with your position |
| 16:51 | <bradleymeck> | ljharb: indeed, but I would like to call a vote |
| 16:51 | <ljharb> | but the compromise was "for Set, you can pass key xor value" |
| 16:51 | <bradleymeck> | if we cannot |
| 16:51 | <ljharb> | i would vote no on principle, a vote is a process failure |
| 16:52 | <ljharb> | even for something i want |
| 16:52 | <ljharb> | it'd be better to never have it than to have to vote on it imo |
| 16:52 | <bradleymeck> | key xor value causes the problem that was the argument |
| 16:52 | <bradleymeck> | i will call a vote if we get to that point, i just want to know the process |
| 16:53 | <bradleymeck> | for now we can continue discussion but it is perfectly valid to call a vote in our process just unclear how |
| 16:53 | <ljharb> | i think only chairs get to "call a vote" |
| 16:53 | <bradleymeck> | unclear |
| 16:53 | <ljharb> | it's valid for committees to have votes and to set their own process |
| 16:53 | <ljharb> | ours is "no votes, just consensus" |
| 16:53 | <bradleymeck> | that is not true |
| 16:53 | <ljharb> | so it takes the chairs to override that |
| 16:53 | <bradleymeck> | thats informal? |
| 16:53 | <ljharb> | which part |
| 16:53 | <bradleymeck> | the no votes, just consensus |
| 16:54 | <ljharb> | i mean, i don't think this is even productive. if you have to rules lawyer to get your proposal in, it's not a good proposal |
| 16:54 | <ljharb> | if someone is immovable, then that's that |
| 16:54 | <bradleymeck> | because of property naming |
| 16:54 | <ljharb> | because of *literally any reason* |
| 16:54 | <bradleymeck> | you can call my proposals not good if you want |
| 16:54 | <bradleymeck> | that doesn't change them |
| 16:54 | <bradleymeck> | discussion changes them |
| 16:55 | <bradleymeck> | right now we have a hard blocker where 2 people are blocking on a bikeshedding issue |
| 16:55 | <bradleymeck> | i believe a bikeshed level issue is perfectly good to call a vote on |
| 16:55 | <bradleymeck> | if compatibility concerns can be shown thats different |
| 16:56 | <ljharb> | i love your proposal |
| 16:56 | <ljharb> | but i don't think *any* proposal is worth a vote |
| 16:56 | <ljharb> | it's not just a bikeshed issue tho. his concern is the runtime interchangeability, which even if you (and i) don't think that's sensible, isn't just about naming |
| 16:57 | <ljharb> | and again, waldemar compromised, so at the moment, you're the only one refusing to do so |
| 16:57 | <bradleymeck> | the compromise does not address the issue raised so it should not be taken to address the issue |
| 16:58 | <bradleymeck> | that would be just taking the change to move it forward |
| 16:58 | <ljharb> | waldemar thinks it addresses waldemar's issue |
| 16:58 | <bradleymeck> | even if the reason isn't sensical and it persists the issue |
| 16:58 | <bradleymeck> | i believe it causes the issue |
| 16:58 | <ljharb> | ok but it was waldemar's issue |
| 16:58 | <bradleymeck> | and the compromise causes the issue raised |
| 16:58 | <ljharb> | only if you treat maps and sets interchangeable |
| 16:59 | <bradleymeck> | so it isn't really a solution even if it is a political standpoint |
| 16:59 | <ljharb> | which you and i both won't be doing |
| 16:59 | <bradleymeck> | treating sets/maps as reusing that object bag was the issue |
| 16:59 | <ljharb> | if waldemar's the only one who will run into it, and he's happy with the compromise, why does it matter if you think it solves it for him or not? |
| 16:59 | <bradleymeck> | because it causes the API to go from partial reusability to a very odd non-reusability matrix |
| 17:00 | <ljharb> | it's either "for maps, you can pass key and/or value" and "for sets, you can pass key xor value" |
| 17:00 | <ljharb> | so you can reuse any object with key xor value |
| 17:00 | <ljharb> | and you can't reuse any object with key and value |
| 17:00 | <ljharb> | which would be true with your proposal anyways, if set didn't take "key" |
| 17:00 | <bradleymeck> | and it causes more confusion on the issue of what does what, things like {...ObjWithKey, ...ObjWithValue} would both be valid in isolation but not when merged in that object bag |
| 17:00 | <ljharb> | (silently not mapping the keys isn't "reusable", that's a footgun) |
| 17:01 | <bradleymeck> | sets don't have keys so 🤷 on that point |
| 17:01 | <ljharb> | iow, i'd say even if Set only took value, it should still throw on key |
| 17:01 | <ljharb> | means the "reusability" of the options bag would be the same either way |
| 17:01 | <ljharb> | it's just about whether you can use *either* name with set, or just one |
| 17:01 | <bradleymeck> | we don't have any precedent on that eager throwing in the spec due to reuse nor any standard API that I know of |
| 17:02 | <bradleymeck> | adding a one off design pattern is very confusing |
| 17:02 | <ljharb> | throwing when you pass conflicting things? |
| 17:02 | <ljharb> | i'm pretty confident Intl has tons of it, for one |
| 17:02 | <ljharb> | also i'm quite sure we have a few in 262, let me hunt them down |
| 17:02 | <bradleymeck> | throwing when both are mutually exclusive yes, not when you provide a value that wouoldn't be used |
| 17:03 | <ljharb> | ah |
| 17:03 | <ljharb> | well, fair, but if people think it's sensible to reuse the options bag across types, then i think it's a hazard we don't want to create |
| 17:03 | <ljharb> | iow if there's no protections, i'd want the option names to have no overlap |
| 17:03 | <ljharb> | iow if map uses "value" then set can't, and vice versa |
| 17:04 | <bradleymeck> | i was fine with renaming it elements but that was another discussion about the names needing to be reused |
| 17:04 | <bradleymeck> | for sets* |
| 17:04 | <bradleymeck> | so we got dragged back into only having toKey or toValue |
| 17:04 | <ljharb> | right, so this is in no way bikeshedding |
| 17:04 | <bradleymeck> | we even showed all those languages that call them elements |
| 17:05 | <ljharb> | this is about "is it meant to be reused, or not" |
| 17:05 | <bradleymeck> | the demand was it must be reused |
| 17:05 | <ljharb> | if it is, then imo it needs to either work as intended, or throw |
| 17:05 | <ljharb> | otherwise people will reuse it and get the wrong answer |
| 17:05 | <bradleymeck> | reuse was not intended but familiarity was |
| 17:05 | <bradleymeck> | the demand of reuse is the problem and there is no room afforded |
| 17:06 | <bradleymeck> | so, I would like to present on the issues, and be able to call a vote |
| 17:06 | <bradleymeck> | i'm unclear on if the vote will be anything more than "must we allow reuse of these objects" |
| 17:07 | <bradleymeck> | the vote wouldn't be on advancement |
| 17:07 | <ljharb> | why would we vote on anything that's not advancement |
| 17:07 | <ljharb> | it makes no sense to me to vote on silencing someone's concerns |
| 17:08 | <ljharb> | progress is not more important than enfranchisement |
| 17:08 | <bradleymeck> | ljharb: just because a topic prevents advancement does not mean we should advance something if that topic is removed from the discussion |
| 17:08 | <ljharb> | right but no topic can ever be removed from discussion entirely (separate from, moving the venue between plenary and elsewhere) without effectively oppressing those who wish to discuss it |
| 17:09 | <bradleymeck> | they still have the right to vote and present their case to sway the vote in either direction |
| 17:09 | <ljharb> | they have the right to block advancement forever even if they don't persuade anyone else, that's how tc39 operates |
| 17:09 | <bradleymeck> | they are welcome to discuss things, but not mandate things |
| 17:09 | <bradleymeck> | ljharb: that is not in our by laws |
| 17:10 | <bradleymeck> | i can mandate we never advance any proposal indefinitely |
| 17:10 | <bradleymeck> | but that doesn't mean the committee must never move JS forward |
| 17:14 | <ljharb> | i think it does and also should mean that |
| 17:15 | <bradleymeck> | well we don't have consensus on that heh |
| 17:15 | <ljharb> | lol |
| 17:15 | <ljharb> | we used to, and previous consensus lasts forever until new consensus changes it |
| 17:15 | <ljharb> | again, i think if you have to resort to rules lawyering then you're basically trying to destroy the process that's kept things working since ES4 failed |
| 17:15 | <bradleymeck> | but as a test, i can do this for the next few meetings but this mimics what happened in Munich |
| 17:15 | <ljharb> | and i think if it happens, it will open the gates to many more such votes. |
| 17:15 | <ljharb> | how so |
| 17:15 | <bradleymeck> | correct |
| 17:16 | <ljharb> | which would be bad |
| 17:16 | <ljharb> | there weren't any votes in munich i can recall |
| 17:16 | <bradleymeck> | me breaking consensus on purpose for political reasons as a means of using our process against itself |
| 17:17 | <bradleymeck> | i mean, i could |
| 17:17 | <ljharb> | right but why would you want to |
| 17:17 | <bradleymeck> | but as it stands there is little actual discussion if a mandate is placed down since there is no counter argument nor balance to a mandate/demand |
| 17:17 | <ljharb> | how is *this proposal* that important to be worth risking the entire way tc39 works |
| 17:18 | <bradleymeck> | ljharb: because thats how oour process works and I want to show something about the process itself |
| 17:18 | <ljharb> | so you're setting fire to everything to make a point? |
| 17:18 | <bradleymeck> | ljharb: indeed, but to me votes are not necessarily as risky |
| 17:18 | <ljharb> | i don't think the devil needs an advocate |
| 17:18 | <bradleymeck> | i think the way we discuss things has become increasingly black and white and it isn't good |
| 17:18 | <ljharb> | it is a *good thing* that any proposal can be forever blocked by even one person, and many bad proposals have been prevented that way |
| 17:18 | <ljharb> | ok so then, have that discussion in good faith |
| 17:19 | <ljharb> | you don't need to attempt to manipulate everyone into understanding your point to do that |
| 17:19 | <bradleymeck> | i intend to, but with the ability to vote determined |
| 17:19 | <bradleymeck> | i am not seeking to manipulate anyone on my proposal |
| 17:19 | <ljharb> | if you are even attempting to bring about a vote, you are |
| 17:19 | <bradleymeck> | how so? we are allowed to bring votes |
| 17:20 | <ljharb> | what is allowed is irrelevant |
| 17:20 | <ljharb> | we're allowed to do lots of things. the social contract sits above that. |
| 17:20 | <bradleymeck> | but ignoring the issues of how we reach consensus is bad |
| 17:20 | <ljharb> | sure. and destroying the consensus process leaves those issues ignored |
| 17:20 | <bradleymeck> | destroying it seems like it might be the only way to bring balance to aspects of it |
| 17:21 | <bradleymeck> | since we cannot have any affect on demands otherwise |
| 17:21 | <bradleymeck> | so, showing demands consistently is a way to highlight that |
| 17:21 | <ljharb> | we'll never have it again if it's destroyed. |
| 17:21 | <ljharb> | and the "balance" we have *is* our consensus process |
| 17:22 | <ljharb> | i think you are sorely underestimating the damage that will be caused by moving to votes |
| 17:22 | <bradleymeck> | that doesn't seem balanced if single party can hold hostage the rest |
| 17:22 | <ljharb> | that is the balance |
| 17:22 | <ljharb> | convince everyone, or it doesn't deserve advancement |
| 17:22 | <bradleymeck> | so it is fair that I prevent all progress |
| 17:22 | <bradleymeck> | ? |
| 17:22 | <ljharb> | yep |
| 17:22 | <ljharb> | go for it |
| 17:23 | <ljharb> | better to prevent all progress forever than to let *one* bad proposal in |
| 17:23 | <ljharb> | (obviously, someone who obstructs in bad faith repeatedly would likely find themselves removed from the committee) |
| 17:23 | <bradleymeck> | i do not find it to be in bad faith, i just have to present arguments for each |
| 17:23 | <ljharb> | but in this case, as in most others, the lone objector is doing it in good faith. |
| 17:24 | <ljharb> | if you *have* those arguments, then you should definitely present them, always |
| 17:24 | <bradleymeck> | good faith is not the sole quantity needed for meaningful discussion |
| 17:24 | <ljharb> | if that means nothing proceeds, then good! you blocked bad things |
| 17:24 | <ljharb> | no, but it's the foundational one |
| 17:24 | <bradleymeck> | i mean, all i have to do is demand things really |
| 17:25 | <bradleymeck> | which isn't hard |
| 17:25 | <bradleymeck> | i mean we block on growing the STDLIB too large |
| 17:25 | <bradleymeck> | just stating that something adds too much complexity is semi-common |
| 17:26 | <bradleymeck> | this is all tangential though |
| 17:26 | <bradleymeck> | there was a fun Monk episode about a juror who was always voting the opposite of the rest to intentionally prevent a conclusion |
| 17:27 | <bradleymeck> | i see it as somewhat similar, preventing a conclusion in itself may be the point |
| 17:27 | <devsnek> | I remember in the modules group |
| 17:27 | <devsnek> | it would turn to a vote without consensus |
| 17:27 | <devsnek> | in which case why bother having the consensus check |
| 17:27 | <bradleymeck> | well without 2 way communication consensus breaks down |
| 17:28 | <bradleymeck> | my stand is that this issue has reached the end of 2 way communication. I got angry enough that I wanted to drop the proposal for quite some time |
| 17:29 | <bradleymeck> | satisfying one blocking point doesn't mean no new points come up due to that |
| 17:29 | <devsnek> | how far does the idea that a set is a map of T => null go in js |
| 17:29 | <bradleymeck> | for example with my complaint about how we cannot take that compromise due to it causing the exact issue that it tries to stop |
| 17:30 | <bradleymeck> | devsnek: not very far in the spec itself |
| 17:30 | <devsnek> | lol fair, I meant observably |
| 17:30 | <devsnek> | different method names at least |
| 17:30 | <bradleymeck> | not very far since values are the "keys" |
| 17:31 | <bradleymeck> | it kinda is like a T => T |
| 17:31 | <bradleymeck> | observably they are quite similar but it isn't like you can call Map methods on a Set nor are the APIs the same for get/set ops |
| 17:32 | <bradleymeck> | they just have a similar collection interface |
| 17:32 | <bradleymeck> | not necessarily generic to those 2 types, if we introduced a RadixTree or something it could have the same level of overlap probably |
| 17:44 | <bradleymeck> | if you consider Arrays our Queue/Stack collections it gets a bit weirder too |
| 18:01 | <ljharb> | ftr, again, i agree that trying to reuse between Map and Set doesn't make much sense |
| 18:01 | <ljharb> | but the compromise waldemar and i came up with is something that allows him to do it, and doesn't interfere with the rest of us who won't be |
| 18:01 | <ljharb> | so i'm still hopeful that's what we can go with |
| 18:21 | <bradleymeck> | it causes the issue it sought to avoid, we should not go with it |
| 18:26 | <ljharb> | i don't agree |
| 18:26 | <ljharb> | and neither does the only person with the issue, waldemar |
| 18:27 | <ljharb> | it seems pretty ridiculous that you're going to block a compromise because you don't think it solves "not your issue" |
| 18:27 | <bradleymeck> | i think it causes a new issue? |
| 18:27 | <bradleymeck> | of the same nature |
| 18:28 | <bradleymeck> | it isn't that it doesn't solve the issue requested, it is that it causes the issue requested |
| 18:29 | <bradleymeck> | i stand somewhat in the same boat of don't pass through proposals if they may be bad here |
| 18:30 | <bradleymeck> | that design would make part of the proposal have a problem from my viewpoint, oddly enough the exact same problem that is the reason to adopt the design |
| 18:30 | <ljharb> | only if you're attempting to reuse an object bag that has both key and value in it |
| 18:30 | <ljharb> | which can't ever work in any design |
| 18:31 | <ljharb> | the difference is that in the compromise, it throws for that case - in your preferred proposal, it silently does the wrong thing. |
| 18:31 | <ljharb> | since it can't ever do the right thing, it's just a question of whether it's a hazard, or a helpful exception |
| 18:31 | <ljharb> | for some reason you're arguing for it being a hazard. |
| 18:33 | <bradleymeck> | i'm arguing a variety of things, notably that the exception isn't helpful nor is the xor like behavior |
| 18:33 | <bradleymeck> | and those come from that design choice |
| 18:33 | <bradleymeck> | and that design choice comes from a mandate of reuse |
| 18:34 | <ljharb> | i think a vote to silence anyone's mandate will lead to a world where anyone's can be silenced, and i simply don't think it should be on the table. if you call for a vote for this, i'll call for another one asking to never again permit us to do so. |
| 18:35 | <ljharb> | (even it's allowed in the first place, which i suspect/hope it's not) |
| 18:36 | <bradleymeck> | not to silence, but to force a choice. it may not go in my favor |
| 18:36 | <bradleymeck> | modules wg stuff in node certainly didn't always go in my favor |
| 18:37 | <ljharb> | yes, i'll then be calling for a vote to disallow ever again forcing a choice |
| 18:37 | <ljharb> | every block matters, or none of them do |
| 18:37 | <ljharb> | even the ones i think are stupid |
| 18:37 | <bradleymeck> | we can argue about that certainly |
| 18:48 | <Bakkot> | ljharb, I don't think ECMA's rules give us enough flexibility to vote on never voting |
| 18:49 | <Bakkot> | one of the things - really the main thing - that you get from joining ECMA is the ability to vote on things |
| 18:50 | <ljharb> | not never voting |
| 18:50 | <ljharb> | never voting on silencing blocks to consensus |
| 18:51 | <bradleymeck> | even if we vote we don't need to have these be reusable that doesn't give us consensus |
| 18:51 | <ljharb> | but also, tc39's consensus rules mean you don't actually need to vote to have an impact |
| 18:51 | <ljharb> | bradleymeck: voting to allow advancement without consensus is the problem |
| 18:51 | <ljharb> | whether you're asking for advancement yet or not isn't the point |
| 18:51 | <bradleymeck> | it doesn't allow advancement |
| 18:51 | <ljharb> | then it doesn't mean anything |
| 18:51 | <bradleymeck> | it constrains design |
| 18:51 | <ljharb> | then it's just a straw poll |
| 18:51 | <bradleymeck> | how so? you have eliminated a design space |
| 18:52 | <ljharb> | the only thing we make decisions on is advancement |
| 18:52 | <bradleymeck> | that isn't true, we also vote on by laws and various other things |
| 18:52 | <ljharb> | ok sure |
| 18:52 | <ljharb> | but "design space" isn't part of that |
| 18:52 | <ljharb> | the design space is always whatever we all think it is |
| 18:52 | <bradleymeck> | we had a bunch of this regarding the allowance of the incubator calls at all |
| 18:52 | <bradleymeck> | which are about designs being done |
| 18:52 | <ljharb> | because there was concern about advancement happening there |
| 18:52 | <bradleymeck> | not just advancement but decisions |
| 18:53 | <ljharb> | design has already been happening outside plenary, and will continue to do so no matter who wishes otherwise |
| 18:53 | <ljharb> | and the only decisions the committee makes about proposals is advancement |
| 18:53 | <ljharb> | design decisions aren't binding |
| 18:53 | <bradleymeck> | agreed, but design is often a central part of our meetings about if a design is something we want to approach |
| 18:53 | <ljharb> | sure |
| 18:53 | <bradleymeck> | design decisions aren't binding why? |
| 18:54 | <ljharb> | but the outcome of that doesn't bind anything |
| 18:54 | <ljharb> | because they can change at any time? |
| 18:54 | <bradleymeck> | i mean, we could change the JS spec anytime |
| 18:54 | <ljharb> | decorators had lots of design decisions, that were presented to the committee, that when asking for stage 3 advancement got rejected |
| 18:54 | <ljharb> | design decisions are just attempts to make advancement more persuasive |
| 18:54 | <bradleymeck> | sure, but they got constrained designs in order to ask for that |
| 18:54 | <ljharb> | sure. from consensus. |
| 18:54 | <ljharb> | since consensus is required for advancement |
| 18:55 | <ljharb> | voting to "unconstrain" a design is voting to not require consensus for advancement |
| 18:55 | <ljharb> | otherwise it doesn't mean anything |
| 18:55 | <bradleymeck> | sure, but consensus on advancement is not the same as design constraints |
| 18:55 | <bradleymeck> | i'm not voting to unconstrain, unconstrain doesn't make sense to me |
| 18:55 | <ljharb> | they're pretty tightly related |
| 18:55 | <bradleymeck> | we have 2 competing design constraints |
| 18:55 | <ljharb> | sure |
| 18:56 | <ljharb> | and the options are either, pick one, or, deadlock |
| 18:56 | <bradleymeck> | that is my summation of the scenario, correct |
| 18:56 | <ljharb> | any vote would be to force one of those three options through advancement, which would be overriding consensus |
| 18:57 | <bradleymeck> | it doesn't force it through advancement? if it cannot advance it cannot advance |
| 18:57 | <bradleymeck> | i can keep bringing it to the committee but to my knowledge Waldemar doesn't participate out of plenary that I've noted |
| 18:58 | <Bakkot> | ljharb I don't think ECMA's rules give us enough flexibility to vote on not voting on any particular topic, if a member wants to call for a vote |
| 19:01 | <ljharb> | i mean sure, but what’s the point of voting on something that doesn’t actually change anything |
| 19:02 | <ljharb> | i can call for a vote on the committee’s favorite color, but it’d just be a waste of time |
| 19:02 | <bradleymeck> | it seems like it does change what can be discussed to me at least |
| 19:02 | <ljharb> | everything can always be discussed |
| 19:02 | <ljharb> | a vote can’t change that |
| 19:02 | <ljharb> | otherwise every “banned topic” will just be another call for a vote, over and over |
| 19:02 | <bradleymeck> | a vote can certainly change what affect discussions can have |
| 19:02 | <ljharb> | but it can’t stop me calling for a vote |
| 19:03 | <ljharb> | so we can vote on the outcome of the same decision a thousand times in a row |
| 19:03 | <bradleymeck> | if a discussion cannot affect the design that means you have to evaluate the existing design to see if it is +/- |
| 19:03 | <bradleymeck> | could remain - |
| 19:03 | <ljharb> | that’s a straw poll, something that delegates have considered harmful in the past when requested |
| 19:05 | <bradleymeck> | it doesn't seem like a straw poll since it does constrain things |
| 19:06 | <bradleymeck> | the proposal for example may lose its utility or capability that makes it worth advancement by making such a choice |
| 19:06 | <bradleymeck> | but currently we are arguing that a capability must be included regardless of the rest of the proposal |
| 19:07 | <bradleymeck> | any vote hurts the proposal's viability |
| 19:07 | <bradleymeck> | but it seems to me a path towards more progress than no vote |
| 19:09 | <bradleymeck> | understanding why no progress is being made could be useful, but that wouldn't by itself lead towards progress |
| 19:09 | <bradleymeck> | hence me wanting to know how to properly call a vote before investing in something that doesn't appear to have a path forward in the status quo without a vote |
| 19:10 | <bradleymeck> | progress could simply be we don't want such a proposal |
| 19:12 | <bradleymeck> | then again i've had talks with people about voting that make me feel that my opinion may differ. i was shocked to learn abstain was treated as a nay regarding spec publication |
| 19:17 | <ljharb> | sure, because “no progress” is fine, “progress” may not be. |
| 19:17 | <ljharb> | this is a standard, not a product |
| 19:18 | <bradleymeck> | progress of dropping a proposal is fine |
| 19:18 | <bradleymeck> | progress can still happen even if the standard doesn't adopt things |
| 19:35 | <ljharb> | indeed. so why is it that important that you need a vote to make progress? |
| 19:37 | <bradleymeck> | i feel a great desire to move this proposal, if I move it such that we don't want to see it again that is preferable to the current state in my perspective. |
| 19:37 | <bradleymeck> | such a feeling might not be shared or considered important by others |
| 19:38 | <ljharb> | your desire to move it is outweighed, though, by your belief that the compromise i've mentioned is a bad idea |
| 19:38 | <bradleymeck> | moving it isn't simply forward towards advancement to me |
| 19:38 | <ljharb> | then withdraw it |
| 19:39 | <bradleymeck> | the compromise causes issues as I've stated in my perspective and repeating that you gave me a choice isn't going to remove my concerns about it |
| 19:39 | <ljharb> | i'd much rather see this proposal that i strongly desire withdrawn, than see a vote on it |
| 19:39 | <bradleymeck> | i'd rather see a vote and go from there |
| 19:40 | <ljharb> | tbh this just seems spitefully stubborn to me; you don't like someone else's intransigence, so you'll be just as intransigent. |
| 19:40 | <bradleymeck> | i'd be fine using toElement |
| 19:40 | <bradleymeck> | but that was also blocked |
| 19:40 | <ljharb> | we all have to do this all the time, decide between "forever stalemate", or, be the first one to cave |
| 19:41 | <bradleymeck> | i don't think that is a healthy perspective |
| 19:41 | <ljharb> | whether you think the way the committee has always operated or not is healthy doesn't give you license to disrupt it. |
| 19:41 | <ljharb> | if you want a different process, let's discuss proposals for one in good faith |
| 19:41 | <bradleymeck> | it is not a disruption, it is still part of our current form of governance |
| 19:42 | <ljharb> | that voting is technically allowed in no way means voting is a part of how we choose and have chosen to operate |
| 19:42 | <ljharb> | the only reason we vote on the spec itself is because ecma makes us |
| 19:42 | <ljharb> | again, you're focusing on a literal evaluation of rules, and i'm saying that's irrelevant in the face of the more important governance, the social contract. |
| 19:43 | <ljharb> | which is vague and nuanced and undocumented but still is how things are done |
| 19:43 | <bradleymeck> | i do not agree with the social contract being the highest priority |
| 19:43 | <bradleymeck> | i agree that votes are not what we desire to do |
| 19:43 | <bradleymeck> | but they are something we are allowed to do |
| 19:43 | <ljharb> | *technically* yes |
| 19:43 | <bradleymeck> | and i think we should do in this situation |
| 19:44 | <ljharb> | but in any context, i'd say winning a debate on a technicality is a dishonorable way to win |
| 19:44 | <ljharb> | even if it's necessary at times |
| 19:44 | <bradleymeck> | i do not see it as such, but you can see it as dishonorable if you wish |
| 19:44 | <ljharb> | i'm more concerned about the precedent it definitely will set, then about this specific topic |
| 19:45 | <bradleymeck> | well we are in a situation of stalemate like you said and I find it compelling enough to call a vote to break out of it |
| 19:46 | <bradleymeck> | repeating the various options doesn't seem to get us a direction to go with |
| 19:48 | <bradleymeck> | convincing me to not call a vote would be difficult given my options of how the API is being pulled in different design directions, helping me phrase a question to give to the committee would be helpful and likely be a different meeting than me discussing the state of the proposal |
| 19:48 | <ljharb> | why this stalemate and none of the previous ones? |
| 19:51 | <bradleymeck> | my personal desire for this proposal and/or being relieved of it is higher and the design constraints themselves appear to be in conflict rather than semantic problems |
| 19:52 | <bradleymeck> | I do not want to give it up as I fear that the xor design would be pushed forward which I find to have its own issues |
| 19:52 | <bradleymeck> | so I don't think abandonment is a discrete option I'd like to take either |
| 19:52 | <ljharb> | if you don't destroy consensus by calling a vote, you don't have to be a champion to ensure that doesn't happen |
| 19:52 | <bradleymeck> | we have passed things in the past due to absence of objectors and I have no desire for that |
| 19:52 | <ljharb> | when objections have been made clear in the past, the absence of that objector generally doesn't mean the objection fades |
| 19:53 | <ljharb> | iow, i don't think you'd have to be present for your objection on this proposal to stand |
| 19:54 | <bradleymeck> | that has not been true to my memory |
| 19:54 | <bradleymeck> | we don't actively even track those when calling a vote |
| 19:54 | <bradleymeck> | for consensus* |
| 19:56 | <ljharb> | no, but people bring them up in good faith |
| 19:56 | <ljharb> | i certainly have, at least |
| 19:58 | <bradleymeck> | mind you i might never even call a vote in this but i would want to know how to properly do so |