Both GitHub and Cursor’s response seems a bit lazy.
Technically they may be correct in their assertion that it’s the user’s responsibility. But practically isn’t part of their product offering a safe coding environment? Invisible Unicode instruction doesn’t seem like a reasonable feature to support, it seems like a security vulnerability that should be addressed.
It's funny because those companies both provide web browsers loaded to the gills with tools to fight malicious sites. Users can't or won't protect themselves. Unless they're an LLM user, apparently.
OP already hired H-1B in the past and that person is working for them now. OP is now in the process of doing a green card application for said employee. They can't move forward with the GC application because there are other qualified citizens/residents, but they don't have to fire the existing H1B employee.
That's how I understand OP, if that's legally true or not, I don't know.
You're correct that they are under no obligation to fire the employee on the H-1B. (In theory, they are applying for a "new" job, and them not getting it for whatever the reason isn't an issue for their current job and status.)
However, what OP is missing is that rejecting the US citizen application based on their citizenship is still likely a prohibited discrimination case regardless of what they do with the existing employee.
OP isn't rejecting the US citizen application because they are a US citizen - they are rejecting all candidates applying for the position regardless of ability to do the job or not since the position is already filled. There was no intent to fill the position to begin with - just a test to see if they can sponsor the current h1b employee for their greencard or not. There is no discrimination if no applicant had a chance of being hired to begin with.
They might be running afoul of discrimination laws if they only interview US citizens to cut down on their workload for fake interviews, but I'd guess someone this careful (e.g. not actually submitting the greencard sponsorship where many employers would with a wink and a nod) is likely careful enough to not filter candidates on such obvious things either.
It's a problem with the h1b (and green card) program itself, not OPs behavior. If anything, OP is probably in the top few percentile of ethical businesses/managers if they are actually denying the sponsorships because they made a good faith attempt to test to see if the local market had appropriate candidates.
I think the issue is that they would hire at least one noncitizen if they apply (the "target" employee). So the odds are absolute zero for citizens, and higher for noncitizens.
As for actually submitting the application--as I understand they actually audit the job ad responses and your decisions--so if you didn't even pretend to have a reason for not hiring them, you would automatically be in a lot of trouble. The game is to come up with flaws in the citizen candidates by requiring highly specific experience--e.g. "JDK v17.0.9 Programming" vs "experience with Java" to justify your target being the only one qualified. That would ultimately be for the court to decide.
Only interviewing citizens to the exclusion of PR/EAD card holders as in your example as written would be a violation.
What I think you meant though, which is not interviewing those who don't have permission to work (without your future attempt to get it for them) is normally completely fine; however, this situation is a little different since you would be willing to provide that for the "target" employee but not the other applications. However, I still don't think it would run afoul of this particular law.
Interesting.
So practically, they would have to hire the new applicant and then let go of the h1b worker because presumably they don’t have the budget for it?!
This is such an ignorantly engineering centric perspective.
There is value in the larger organization being able to consume documentation and commenting on it and contributing to it.
There is conceptual value in some of these things, but I find it to be overstated and the downsides entirely ignored.
Most documentation systems have a version history.
And most documentation systems are far easier adopted by people other than engineers.
This is the equivalent of pointing out that figma has x, y, and z benefits and designers are fluent in it, so we should be using that for documentation.
> This is such an ignorantly engineering centric perspective.
I gather this is for technical documentation. For people who either are engineers or who work closely with engineers.
> There is value in the larger organization being able to consume documentation and commenting on it and contributing to it.
Agreed! One benefit of "docs as code" as this person calls it is that you can pile tools and metadata on top of it. People have created excellent tools to comment on and make suggestions to Git pull requests, for instance.
> And most documentation systems are far easier adopted by people other than engineers.
That really will depend. And no matter how good the software is, you're likely going to be locked into one corporate service provider. If you instead treat documentation like you do code, you'll have access to a wide variety of wholly interoperable UI alternatives with no threat of lock-in.
> And most documentation systems are far easier adopted by people other than engineers.
Whew, gonna have to have a hard disagree with you there. DaC is several times - nay, orders of magnitude - less complicated than standing up a S1000D, a DITA, or even a DocBook publishing system. For anyone.
Count the layers of configuration.
S1000D, you have to worry about issue (which has zero compatibility, and the Technical Steering says they have zero intention of releasing any guide to matching the different issues up), you have to worry about BREX, then you have to worry about bespoke DMC schemes, and then you have all the many ways the PDF or IETM build can get built out to Custom Solution X, since the TS/SGs offer absolutely bupkiss for guidance in that department (it's a publication specification that doesn't specify the publication, what can I say?). The DITA side's not a lot better: you have multiple DITA schemas, DTD customization, specialization, and you have a very very very diverse batch of DITA-OT versions to pick from, then on top of that you have the wide wide world of XSL interpreters, again with very little interplay. DocBook is probably the sanest of the bunch, here, but we're still going to be wrestling with external entities, profiles, XSL, and whether we're doing 4.X or 5 or whatever is in DBNG.
Not to mention all of this stuff costs money. Sometimes a whole lot of it. Last time I shopped round, just the reviewer per seat licenses for the S1000D system were 13k per seat per year, the writer seats were over 50k per year.
DaC, on the other hand, I want to get re-use and conditionals, so I get Visual Studio Code. I get Asciidoc. I get some extensions. I get gitlab, set up whatever actions I want to use, set up the build machine if I want one, and if I'm feeling adventurous, Antora. I'm literally writing an hour later. I'll probably spend more time explaining to the reviewers what a Pull Request is.
Github ux is an unmitigated disaster from an operational security perspective.
In their defense, it did start out as an open-source tool.
The fact that enterprises adopted it so blindly despite this is pretty interesting.
It really didn't start out as an open-souce tool. Github was founded for selling private repo access for Git and got popular in the FOSS community since they provided free storage.
Correct.
Unclear wording on my part.
If you build a product that is meant to be used by the open source community, you build features which are at odds with companies’ needs that care about keeping their code proprietary.
However, their business goal has always been targeting proprietary software companies. Open source support has always been the marketing part of their business. It basically falls apart whatever view you take:
If Github are building a free-as-in-free-beer tool for open source ecosystem, being a for profit company that tries to make money from proprietary software companies doesn't make sense.
If Github are a for profit company building paid tooling for paying customers who want to keep their software proprietary, then narrow mindedly designing their tooling as if everything is out in the open doesn't make sense.
Both cases show they are either naive, incompetent or in a serious misunderstanding about who their customers are.
> Apple has and (probably is still) extending unpublished entitlements to developers that allow for behavior that is not publicly documented.
Sure, but that's fine. You bought a product that the manufacturer claims does "X", but someone else with the same device has access to feature "Y" because they paid more or whatever. Totally legal market segmentation, no different for a phone than a dishwasher or car or whatever.
Apple got in trouble here because they secretly modified phones (that it turned out couldn't do "X" without crashing) to do "Z" instead, which was slightly inferior, and didn't tell the owners (presumably to avoid having to compensate them). Can't do that with a dishwasher or car either.
Your point is absolutely correct and as far as I can tell you pointed it out genuinely, not facetiously.
Edit: read other later posts here: didn’t know about the bacteria part. Learned something today!
This is absolutely not my area of expertise but intuitively there are two categories of energy sources: one which releases co2 (or other climate change impacting gases) and one which doesn’t. Wood, oil, gas, coal falls into the former. It’s just a question of time as you say until the loop closes. Solar, wind, thermal, etc would fall into the latter as far as I can tell.
Most wood burning happens in more rural areas where people are harvesting the renewing resource on their own land, like fallen trees in winter. Many times, areas need to do controlled burns to prevent uncontrolled wild fires, and it's better to manage that burning for a purpose, useful heat, that lessens the heat needed from other energy sources that aren't renewable.
In California’s mountains (Sierra Nevada range and similar) people who want to burn wood legally have to use pellets. The stoves that burn them are meant to comply with pollution regulations. People kinda don’t like them but they use them.
Montevideo didn’t seem like a place where suburbanites were burning wood of any form, but I was there in the summer, just for a day.
