Bikesheds Re: [selectors-api] Consider backporting find() behavior to querySelector()
On Wed, 20 Jun 2012 16:26:14 +0200, Lachlan Hunt lachlan.h...@lachy.id.au wrote: On 2012-06-20 10:42, Charles McCathieNevile wrote: In other words we have the same arguments that we had five years ago, when we settled on querySelector as the one that provoked least objection. ... But spending another few months arguing about it hasn't proven that we are any wiser, nor (importantly) any closer to agreement. This is why it should be an editorial decision, not a group vote. The least-objectionable alternative is rarely the best alternative, and trying to please everyone is a fool's errand. Hopefully, this time, the group will let me, as editor, evaluate the options and supporting rationale and make a decision based on that. Yeah, if that works, it's fine. Back then we were in a position where people cared enough to object, so we chose a different way of making most of the people unhappy that drew less objection... cheers Chaals (You think this is bad, people bikeshed how I should write *my*name* ...) -- Charles 'chaals' McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg kan noen norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: Bikesheds Re: [selectors-api] Consider backporting find() behavior to querySelector()
(12/06/20 22:26), Lachlan Hunt wrote: On 2012-06-20 10:42, Charles McCathieNevile wrote: In other words we have the same arguments that we had five years ago, when we settled on querySelector as the one that provoked least objection. ... But spending another few months arguing about it hasn't proven that we are any wiser, nor (importantly) any closer to agreement. This is why it should be an editorial decision, not a group vote. While I don't think a WG vote is the right way to do, I strongly disagree that naming of a function belongs to an editorial decision. Changing the name of a function requires all the tests be rewritten, and therefore it is by definition not editorial. The least-objectionable alternative is rarely the best alternative, and trying to please everyone is a fool's errand. While I agree that trying to please everyone is foolish, I am curious about data that can be used to prove the the least-objectionable alternative is rarely the best alternative statement. Hopefully, this time, the group will let me, as editor, evaluate the options and supporting rationale and make a decision based on that. I don't know what happened when the WG decided on the poor name querySeletor, but from a outsider's point of view, along with the final decision, I also care about a detailed description about why a function name is chosen. For example, attributing the poor querySelector decision to an abstract concept of design by committee doesn't seem to be reasonable and genuine. I'd rather want to see a long explanation like: Despite the fact the editor thinks function name X is better than 'querySelector', there were a few people (name goes here) who were strongly opposed to X and a group vote happened and a decision was made by (name goes here). Nobody ran a compatibility research. And this time, I would like to ask whoever is going to make the decision to take the opinion of the *public* into account. I am not saying it should be the sole factor, but what I am looking for is an explanation like Compatibility research shows that both name X and Y are fine. 70% of the Web developers are in favor of name X and therefore X is chosen. or Despite 70% of the Web developers are in favor of name X, compatibility research shows that or even Despite 70% of the Web developers are in favor of name X, 100% of browser developers are not and therefore ... or even Nobody ran either a public vote and compatibility research and the editor made the decision on X because he likes it. (Seriously, I don't see why a rationale like this is better than the one for querySelector as this is pretty much just s/WG/editor/ of that since the WG vote didn't represent the public, but at least this is easier to understand than design by committee or design by editor, which is just well, difficult to understand to a causal person who cares about the standard but doesn't have the bandwidth to go in.) In other words, while I can agree that a single +1/-1 statement isn't strong as a rationale (or even not a rationale) I beg you to take the sum as a valid and strong rationale, at least in this case where X and Y don't have much difference. And I am still interested in what really happened last time. (will try to bring real feedback next time.) Cheers, Kenny
Re: Bikesheds Re: [selectors-api] Consider backporting find() behavior to querySelector()
On 2012-06-21 15:56, Kang-Hao (Kenny) Lu wrote: (12/06/20 22:26), Lachlan Hunt wrote: On 2012-06-20 10:42, Charles McCathieNevile wrote: In other words we have the same arguments that we had five years ago, when we settled on querySelector as the one that provoked least objection. ... But spending another few months arguing about it hasn't proven that we are any wiser, nor (importantly) any closer to agreement. This is why it should be an editorial decision, not a group vote. While I don't think a WG vote is the right way to do, I strongly disagree that naming of a function belongs to an editorial decision. Changing the name of a function requires all the tests be rewritten, and therefore it is by definition not editorial. By editorial decision, I meant that the decision of what to name it should be up to the editor, not that it is a minor editorial issue. Sorry for the confusion. Fixing tests is trivial, but the name should be decided before implementation begins and a testsuite is written anyway. At this stage, I haven't seen any overly strong objections to the names find/findAll anyway, so hopefully this is a non-issue. Hopefully, this time, the group will let me, as editor, evaluate the options and supporting rationale and make a decision based on that. I don't know what happened when the WG decided on the poor name querySeletor, but from a outsider's point of view, along with the final decision, I also care about a detailed description about why a function name is chosen. For example, attributing the poor querySelector decision to an abstract concept of design by committee doesn't seem to be reasonable and genuine. I'd rather want to see a long explanation like: What happened last time was that I carefully reviewed the entire debate, taking into account all arguments for and against every suggested alternative I found at the time and posted a thorough review and rationale for the decision I made at the end. http://lists.w3.org/Archives/Public/public-webapi/2007Jun/0077.html This then resulted in some people in the group complaining loudly enough because they weren't happy, mostly because it's impossible to please everyone, leading to a vote between 6 choices, ultimately overruling me. Anecdotally, I heard from a few web developers at the time saying they even liked the names I'd chosen, despite them being a little long, but were later disappointed with the result of the vote. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: Bikesheds Re: [selectors-api] Consider backporting find() behavior to querySelector()
On Thu, 21 Jun 2012 15:56:45 +0200, Kang-Hao (Kenny) Lu kennyl...@csail.mit.edu wrote: (12/06/20 22:26), Lachlan Hunt wrote: On 2012-06-20 10:42, Charles McCathieNevile wrote: In other words we have the same arguments that we had five years ago, when we settled on querySelector as the one that provoked least objection. ... The least-objectionable alternative is rarely the best alternative, and trying to please everyone is a fool's errand. While I agree that trying to please everyone is foolish, I am curious about data that can be used to prove the the least-objectionable alternative is rarely the best alternative statement. I don't think there is any readily available. There are no clear criteria for judging best, although there are some clear criteria for judging bad - for example things that often get confused are definitely bad. Hopefully, this time, the group will let me, as editor, evaluate the options and supporting rationale and make a decision based on that. I don't know what happened when the WG decided on the poor name querySeletor Pretty much what Lachy said. As chair, I was the one who decided there ws too much objection and called for some other process. I don't claim it was especially good or came up with a great name, but I don't think it was awful and I don't see a better alternative if the situation arises again. Despite the fact the editor thinks function name X is better than 'querySelector', there were a few people (name goes here) who were strongly opposed to X and a group vote happened and a decision was made by (name goes here). Nobody ran a compatibility research. And this time, I would like to ask whoever is going to make the decision to take the opinion of the *public* into account. I am not saying it should be the sole factor, but what I am looking for is an explanation like Compatibility research shows that both name X and Y are fine. 70% of the Web developers are in favor of name X and therefore X is chosen. We don't have that data. We don't agree which web developers are the ones whose opinions matter - those who type a name once a month and want something self-explanatory, or those who type it once every 3 minutes, or those who write tools to avoid typing it at all, or ... And then we don't have representative samples. We know, for example, that focus/blur made sense to english-speaking developers but confused millions of developers whose first language was something else. So claiming we are basing a decision on the data will probably give results as arbitrary as the process we used, but with a veneer of intellectual dishonesty. Seriously, I don't see why a rationale like this is better than the one for querySelector as this is pretty much just s/WG/editor/ of that since the WG vote didn't represent the public Sure. In other words, while I can agree that a single +1/-1 statement isn't strong as a rationale (or even not a rationale) I beg you to take the sum as a valid and strong rationale, at least in this case where X and Y don't have much difference. And I am still interested in what really happened last time. (It is instructive to think for five minutes about the things that can go wrong, and how much effort we should spend on trying to get it right) Essentially, a bunch of people tossed up all the reasons to object to a name that they could think of based on their experience of things that go wrong. Based on that, some proposals were rapidly rejected, and then we looked at the rest, kicking the tyres of each in turn until we figured out which one the most people didn't think was truly problematic. It can be dismissed as design by committee, but it can also be characterised as applying the wisdom of several smart people to avoid as many pitfalls as possible. Frankly I think that suggesting one is smarter than any committee of smart people could be is a bold claim - if nobody is especially happy with the outcome, it can often be said that a number of very clever hardworking people recognise that it doesn't have any of several obvious problems they can name, and they think it is an acceptable outcome. cheers Chaals -- Charles 'chaals' McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg kan noen norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: Bikesheds Re: [selectors-api] Consider backporting find() behavior to querySelector()
(12/06/21 23:28), Charles McCathieNevile wrote: On Thu, 21 Jun 2012 15:56:45 +0200, Kang-Hao (Kenny) Lu kennyl...@csail.mit.edu wrote: (12/06/20 22:26), Lachlan Hunt wrote: The least-objectionable alternative is rarely the best alternative, and trying to please everyone is a fool's errand. While I agree that trying to please everyone is foolish, I am curious about data that can be used to prove the the least-objectionable alternative is rarely the best alternative statement. I don't think there is any readily available. There are no clear criteria for judging best, although there are some clear criteria for judging bad - for example things that often get confused are definitely bad. Well, yes, though I wonder why we can't define best to be what gets the most public votes (just in this case, please don't generalize this to cases when X and Y are having different implementation difficulty). Hopefully, this time, the group will let me, as editor, evaluate the options and supporting rationale and make a decision based on that. I don't know what happened when the WG decided on the poor name querySeletor Pretty much what Lachy said. As chair, I was the one who decided there ws too much objection and called for some other process. I don't claim it was especially good or came up with a great name, but I don't think it was awful and I don't see a better alternative if the situation arises again. Thanks for the information (and to Lachy too). I also found the vote[1] itself quite interesting. [1] http://www.w3.org/2002/09/wbs/38482/selectorsNames/results Despite the fact the editor thinks function name X is better than 'querySelector', there were a few people (name goes here) who were strongly opposed to X and a group vote happened and a decision was made by (name goes here). Nobody ran a compatibility research. And this time, I would like to ask whoever is going to make the decision to take the opinion of the *public* into account. I am not saying it should be the sole factor, but what I am looking for is an explanation like Compatibility research shows that both name X and Y are fine. 70% of the Web developers are in favor of name X and therefore X is chosen. We don't have that data. We don't agree which web developers are the ones whose opinions matter - those who type a name once a month and want something self-explanatory, or those who type it once every 3 minutes, or those who write tools to avoid typing it at all, or ... And then we don't have representative samples. We know, for example, that focus/blur made sense to english-speaking developers but confused millions of developers whose first language was something else. So claiming we are basing a decision on the data will probably give results as arbitrary as the process we used, but with a veneer of intellectual dishonesty. I claim that numeric data is as honest as we ever can be. Taking a look at Lachy's summary, I have to say while I appreciate the effort spent on this, there are really just contradictory sentences that made me frown, and Lachy later admitted[2]: [[ In hindsight, looking at the arguments above, I probably did let my own personal dislike of the name get in the way of my objectivity in this case, as much as I tried to avoid doing so. As such, I am now willing to consider these alternatives. ]] . Debating these rationale seems to be a waste of time too. I don't see why doing a public poll can be considered dishonest. The honest description would just be We ran a public poll on (pointer goes here) with X people, Y % of them are Web developers (pointer to the statistics goes here). The result ... [2] http://lists.w3.org/Archives/Public/public-webapi/2007Jun/0120 (It is instructive to think for five minutes about the things that can go wrong, and how much effort we should spend on trying to get it right) Essentially, a bunch of people tossed up all the reasons to object to a name that they could think of based on their experience of things that go wrong. Based on that, some proposals were rapidly rejected, and then we looked at the rest, kicking the tyres of each in turn until we figured out which one the most people didn't think was truly problematic. It can be dismissed as design by committee, but it can also be characterised as applying the wisdom of several smart people to avoid as many pitfalls as possible. Frankly I think that suggesting one is smarter than any committee of smart people could be is a bold claim - if nobody is especially happy with the outcome, it can often be said that a number of very clever hardworking people recognise that it doesn't have any of several obvious problems they can name, and they think it is an acceptable outcome. I never like the design by committee term because it seems to suggest a solution (the benevolent dictator) without explaining what's going on. In the querySelector case, although I admit that I think what
