Document GitHub Desktop gotchas in setup guide

[mmazanec22]

Added section on GitHub Desktop. Happy to ditch this in favor of whatever edits @josephine-njooi is cooking up instead

[josephine-njooi]

Thanks!

[josephine-njooi]

Suggesting to take the second point out, because GH desktop doesn't have an official linux download

[seidior]

I was like "I 100% have used it on Linux" and as it turns out the community-maintained fork by a former GitHub engineer was so good I didn't even know that it wasn't official. While your callout is valid, I wonder if we should still consider recommending that community-maintained fork.

Additionally, GitKraken is a good recommendation for a FOSS git gui. There are also terminal-based git GUIs as well.

[seidior]

Sorry, it got a little philosophical. But I'm genuinely curious as to your, @josephine-njooi's, and @timwright12's thoughts here.

[seidior]

I wonder if there's a benefit in clarifying the difference between Windows apps and applications running in WSL2.

I'm guessing that as an OSS application that was ported to Windows that is Electron-based, it will use some utilities that are built-in and default to shell parameters specific to the environment it's running, not taking up your configuration from PowerShell and definitely not behaving like WSL2.

The bigger, broader question and the thing I'm struggling with is: should we be using this guide with our state agency partners?

This guide was specifically written for OOI engineers who are forced to use the state laptop to get their code working with minimal changes to the code as possible, and to provide them access to the network of open-source tools that they're used to.

The goal of a guide to share with our partners at agencies would be to use Windows-based tools that they're used to, or to focus a guide on getting things running in VMWare or something. Thinking about this some more, I honestly don't think recommending a WSL2-based approach is going to work with technical stakeholders at agencies, much less non-technical stakeholders at agencies.

It's a path that their agencies' IT folks won't be able to support if anything goes wrong, and it'd be a huge ongoing lift to be WSL support for our agency partners across the state.

[josephine-njooi]

My 2c is that I'm the one teaching our agency stakeholders, and I can't teach something I'm not familiar with. So that's a flat no to Windows-based tools. If the same guide was written for VMWare I think that would be fine, but my WSL2 experience so far is that I like it, and I think it does help agency partners stick in a Windows environment that they are more familiar with. And the more familiar I am with something, the easier it is for me to do the handoff. WSL2/maybe VMWare feels like meeting in between with what I know and what technical agency partners know and have.

forced to use the state laptop to get their code working with minimal changes to the code as possible

"minimal changes to the code possible" seems like the same goal to me, for an agency handoff.

I honestly don't think recommending a WSL2-based approach is going to work with technical stakeholders at agencies

I can't speak to what use cases you have in mind, or what you think won't work. But as things are going, the first step (getting one person set up) has worked for doula, and I think will continue to work just fine.

My personal giant pain point with my accessibility tooling I need is having to use Windows at all, and I think having to use VMWare running Ubuntu in a Windows would be worse. Nothing inherent in Talon is incompatible with Windows (in case https://github.com/newjersey/internal-ops/issues/1110 will be for windows), just my the 6 years of custom configs that got forked from before those configs were unified.

[josephine-njooi]

FWIW, my goal with the technical stakeholders is to try to keep things in GUIs as much as possible