scsh

> To drive change in your organization, don't ask "why did this happen?".

> Instead, ask:

> What are we changing so that the same class of failure is less likely next time?

Why are these framed as being almost mutually exclusive? I don't get it. "How/why did this happen?" informs how you answer "What are we changing?" Even the following section, "Reasonable people", functions in this way with a "Why did this happen?" followed by "What are we changing?".

Just feels like this article has some internal conflict with itself in order to achieve a "don't do that, do this" type of style.

> It does not control for commit complexity, security intensity, or bug severity. It does not distinguish between a one-line typo fix and a CVE patch. It is a blunt instrument. But the critics' accusation is also blunt: "Claude is making things worse." A blunt instrument is the fairest response.

If by fairest you mean to say that this analysis and response is sufficient, then I'm sorry but I have to disagree. We really need to understand if the nature of the bugs are worse from a user's perspective. Even if the rate stayed unchanged, if the result is the perceived quality of the software declined then I would personally consider that worse, especially if I were a project maintainer.

That's not meant to be wholly dismissive either. But in general, I don't think quantitative analysis alone is enough to fully answer this type of question.

If you have an internal CRM and are maintaining a Zendesk integration to create support tickets within your product, you've likely already done half the work needed to instead create those tickets in your own internal CRM tool yourself. This makes a lot of sense.

As someone who's had to maintain a Zendesk integration such as this for a large app it's hard to understate the benefit of having all that support info so close to the rest of your user's data. I have seen a huge amount of effort go into trying to get just the right balance of data in and out of ZD. Also helps alleviate concerns with sharing too much customer data with a third party.

This definitely isn't the right call for everyone, but there's a lot of upside if it can work for your organization.

No it's not strange. As someone who enjoys playing music I have heard a lot of music that doesn't suite my particular tastes, but appreciated the artistic talent of the people creating it because I truly believe they are talented. If you dig below the surface level you can find plenty to appreciate about how something is created, even if the product isn't for you.

You can find something to like about a lot of things. I also enjoy watching videos about wristwatch repairs and seeing the construction of them. However, I do not want one and would never wear one.

It wasn't just him making such quotes, as I indicated before, and I made no attempt to make an exhaustive account of such statements which can be easily found elsewhere. It's very reasonable to conclude that that is an issue at play here. That is all I attempted to convey.

Direct quote:

“Venezuela is completely surrounded by the largest Armada ever assembled in the History of South America. It will only get bigger, and the shock to them will be like nothing they have ever seen before — Until such time as they return to the United States of America all of the Oil, Land, and other Assets that they previously stole from us.”

This along with other direct quotes from officials is what led me to the conclusion that, yes, oil is a large factor.

I think these are valid concerns for a project maintainer to think through for managing a chosen solution but I don't think there is a single correct solution. The "correct", or likely least bad, solution depends on the specific project and tools available.

For bug reports, always using issues for everything also requires you to evaluate how long an issue should exist before it is closed out if it can't be reproduced(if trying to keep a clean issue list). That could lead to discussion fragmentation if now new reports start coming in that need to be reported, but not just anyone can manage issue states, so a new one is created.

From a practical standpoint, they have 40 pages of open discussion in the project and 6 pages of open issues, so I get where they're coming from. The GH issue tracker is less than stellar.

They open themselves up to a lot of risk, but more likely they only comply when CA residents are concerned or stop collecting for CA residents. Good question about outside the USA. Makes me wonder if there may end up being some sort of data broker safe havens setup, like we've seen with banking.

Absolutely. What sound pretty cool, and different, here is CalPrivacy would be required to build a request mechanism that's one request sent to every data broker.

The GDPR lets someone request deletion of their data and there are legal teeth to force a business to comply, but that's 1:1. Maybe I need to dig deeper, but this specifically applies to data brokers it seems. That's great and it being a one to many request is fantastic, but sounds like it may not apply to just anyone who has data on you like the GDPR...

The gist of the GDPR in that respect is it allows someone to request a record of what data a particular business has gathered about them as well as request deletion of that data. It also introduced a lot of restrictions around what can be done with a particular subject's data, like sharing with third parties.

The BQ dataset is only ~17GB and the free tier of BQ lets you query 1TB per month. If you're not doing select * on every query you should be able to do a lot with that.

It's available on BigQuery and is updated frequently enough(daily I think).

Probably just forgot to make it public.