colbyrussell

My phone number is listed on my home page. Please give me a call.

I agree with some of what you say—one caveat is that you're still on the hook, for example, for finding out which GitHub URL/repo maps to the project you want to contribute to. In practice, this is roughly on par with the difficulty of finding the link to the self-hosted Bugzilla instance. It's a shame that decentralized single sign-on is still such a disaster, since that's essentially the one thing that GitHub has as a leg up over other options—assuming you've contributed to some other GitHub project before.

To stray outside the lines with some meta-commentary: it's nice to get a well thought out response instead of the sort of kneejerk rooting-for-my-home team that's on display in the wasteland of intellectual dishonesty in the comments below.

It's literally not my stance. And I've literally said that it's not my stance—in a comment (that should have never been necessary to begin with) meant to remove all doubt. And you know this.

To continue saying otherwise (explicitly, even) is a case of outright intellectual dishonesty.

I only counted opening a pull request as a single operation to begin with.

I'm going to try to make this as straightforward as possible: Where in this[1] comment does an error lie? Please make a copy and edit it to reflect what you're saying here and then show me the result.

1. https://news.ycombinator.com/item?id=19779664

I'm going to skip ahead here. You're going to replace the `add unnecessary-third-fork` command with `set-url origin $THIRDFORK`. Either that, or you swap for a `git clone $THIRDFORK` so "origin" is set as a result of the clone.

How many steps do you need to eliminate before you can match the cost first sequence (2 steps)? How many steps does your advice eliminate? What are the total number of steps involved in the GitHub approach? I'll wait for your answer this time.

> If you contribute many times to the same repo, you only have to fork once. If you do a lot of drive-by contributions, you'll end up forking a lot of repositories.

That doesn't contradict anything I've written here, or anything I've written in years past on exactly this topic. But this _entire_ branch of conversation started with someone quibbling that I didn't rank configuration of remotes as a zero-cost operation. So, no, we're not both right.

Yes, exactly. Literally anything that has an upload button in the bugtracker for you attach your patch that fixes the bug.

> you can almost always push to origin

Why am I having to repeat myself here? You can never push to origin unless it's your own project or your team's project.

> It's a constant cost in the same way that looking up where to submit your patch to is a constant cost. You will pay [...] N times, where N is the number of projects you contribute to.

In other words, it's not a constant cost.

You can't push to origin unless it's your own project or your team's. We're talking about PR-based workflows.

> Adding a remote is generally a one-time cost

It's not a constant cost, unless you're saying you only ever intend to contribute to one project ever. It's a fixed cost that you will pay N times, where N is the number of projects you contribute to.

What? You get to imagine some bad argument that would make it most convenient for you, and then demand that I defend that argument, as if it were one that I wanted to make? This is what I'm responsible for? Dealing with someone who resorts to strawmanning the person/idea at the other end when challenged?

Everyone is trying to get me to defend mailing lists. I have no idea why. I haven't said anything about them. In fact, I hate mailing lists.

I'm mystified about what's going on right now.

Both versions involve clicking.

Both versions involve command-line steps.

The difference is that the GitHub version requires more of both, needlessly. That's the point of what I wrote. That's the only point.

I don't understand this context where I'm being forced to defend an argument that's been foisted upon me and that I never made and never even thought of trying to make.

Please explain how you got there, because I'm at a loss. Both examples involve using the CLI. The GitHub version I ran through actually includes more CLI steps. How could that possibly have been my intention?

What makes either of those things harder than what you have to do to use github.com?

Let me ask, do you think that the content of my message reduces to "graphical user interfaces are harder to use than CLI"?

"Easy" like:

    git diff master..bugfix > bugfix.patch # or `format-patch`
    # now attach/upload bugfix.patch

Instead of:

    # make sure you click around github.com to create third fork
    git remote add unnecessary-third-fork $THIRDFORK
    git push unnecessary-third-fork bugfix
    firefox $THIRDFORK # now click around to file a PR
    # now wait for your PR to be merged
    # now click around on github.com to delete $THIRDFORK
    # ... unless you just leave things laying around

What makes the second sequence easier than the first?

This is exactly right. People can pretty easily make their own lunch, and yet every day there are millions of transactions involving people forking over, say, $8 for an overpriced and overspiced pasta dish.

Programmers need to stop looking at the most negative pathological potential that involves not getting paid and then extrapolating that it will be true for everyone in the pool of prospective customers. (That and also stop feeling burned when someone either takes a path that involves not paying or just doesn't bite at all). The sandwich shop doesn't have to capture 100% of the revenue that could be generated by the passing traffic. They just need to do well enough to keep the lights on.

And stop focusing on open source versus commercial software, or how to "run an open source project" and find funding for it. Start selling software that's incidentally open source.

In 2017, I decided that I would (a) start paying for more software, and (b) never again pay for any program that didn't come with source code. (I.e., not even necessarily free software—they just need to have published the source somewhere.) The consequence of that is that I've paid a total of $0 since then. Know how many times I've bought pizza in that time period?

Completely separate from the submission of this link:

I've been working on triplescripts.org, and I have plans to dive into Gnome and GJS, with the goal being to highlight GJS as a potential target for the system layer. Along the way, I intend to pour some energy into the Gnome/GJS docs. In the past, I was heavily involved in shaping the JS docs on developer.mozilla.org in its early days (ca 2006–2008).

For pragmatic reasons, triplescripts.org is "launching" with a focus on NodeJS right now, due to its ubiquity. GJS is a capable alternative, though, especially for environments where you'd expect it to be installed and where NodeJS isn't already, like default Ubuntu installs.

Related:

https://news.ycombinator.com/item?id=15725942