[NUG] *Re: API 2.0

[Norman Palardy]

> On Mar 14, 2019, at 12:10 PM, Jon Ogden via Nug <nug at xojousers.com> wrote:
> 
> 
> Norman,
> 
> I’m not pissed off at you.  I just am amazed that “verified” doesn’t mean what it and 99% of the other people say.  

Agreed - they should change the status to some other name as it leads to exactly the problem we're discussing
It sets the wrong expectation

> Again, if you take the case of the Serial Port bug I pointed out, it’s easy for Stephane or Robin to look at how different states of the RS-232 port give different status results.  It’s quite easy to see it’s a bug.  There’s another one that I found in Cocoa with a key up event firing twice in text fields.  It absolutely does and last time I checked it still does it.  Joe “verified” it years ago.  I’m surprised most people don’t report it and see it as a problem.  But a key up even should never fire twice.  And in both of these cases, I included example programs.  

With my overwhelming responsibility being the IDE there were a LOT of bugs I never looked into 
About the only time I looked into framework bugs was if I was seeing it in the IDE as well
Occasionally I'd poke into some because they made me go "Huh?" and so I'd look

But most of my time was focused on the IDE

> To me reviewed has basically meant, “yeah, I’ve read this and looked at this.”  Verified has meant “yeah, we see we have a bug here”  Because the next step is “fixed and verified” meaning, we fixed the code.  Now, that’s totally different from it being implemented and put into a build to be released.  I understand some time can happen between those two.
> 
And this is why I wish they'd change the names of the statuses because the names mean different things to you and them
An thats where the friction comes from
Users mostly perceive "verified" to mean "verified its a bug" and NOT the internal meaning

I gave up on that fight 

But this is also why from time to time you'd see greg jason etc reminding you that "verified doesnt mean verified as a bug"
They have to explain this because that "verified" is interpreted differently

> Now, you’ve come along and said that what I (and probably everyone else) has believed for years is not correct.  OK.  But my point then is that it’s a terrible line of logic and policy.   

This has been echoed on the forums from time to time as well
But you'd have to be reading that specific thread to see that

> Perhaps fixing a keyup event from firing twice in a text field is a bigger issue than one would think it should be.  But I would think consistently reporting the same information in a serial port should be an easy fix.  Heck I’ve implemented a workaround for it (and for the text field as well).  I’m surprised that for any of these “difficult” bugs that Xojo doesn't put in a workaround if the bug is too complex to fix.  It doesn’t fix it but it hides it from the user so we don’t have to remember to use our own subclasses that implement the workarounds.

Cant say the I've ever run into keyup firing twice on any platform
Doesn't mean it doesn't exist but IF there were lots of folks seeing this it would get fixed (because it would affect lots of people)
I'd guess "lots" would be ... 10 people

> But when engineers like William Yu mark something as “verified” my thoughts are that there’s something to it and my example has shown them the issue.  But I guess not.

And therein lies one more difficulty with "Verified"
Stephane verifying it means "behaves as described"
But an engineer like William verifying it is more likely to mean "yeah and this IS a bug" - but not always

> I agree that I have seen things I’ve submitted fixed very rapidly.  But I’ve also seen stuff languish that I don’t think should.

Right
But despite users paying for the product etc and being able to voice your desires via several means Xojo still sets the schedule - and that is driven by other considerations as I've noted previously

Its not unlike any other company big or small - customers influence the priorities but they dont control them