14 Matching Annotations
  1. Nov 2022
    1. This github "community of people" is apparently more interested in pontificating about pointless differences in tools and wanking off to tool complexity than they are in actually getting shit done.
  2. Oct 2022
    1. The most dangerous form of procrastination is unacknowledged type-B procrastination, because it doesn't feel like procrastination. You're "getting things done." Just the wrong things.

      Type-B procrastination accounts for a lot of the junk I see on people's GitHub timelines—and that type of social network-backed gamified gratification is why I've adopted a stance where I impose a huge entry fee on any workflow that routes itself through GitHub's servers.

  3. Sep 2022
    1. No to new features. No to breaking changes. No to working on holiday. No to fixing issues or merging pull requests from people who are being unpleasant. No to demands that something has to be fixed right now.

      In other words, no to the rotten cultural expectations that are by far what you're most likely to encounter on GitHub. I promise—things really were so much better before it came along to try to be Facebook-for-software-development.

    2. The general state of the open source ecosystem is that most maintainers are building software they want other people to use and find useful.

      I think the default assumption that this is what's going on is a huge part of the problem. I see a similar thing happen on GitHub constantly, where project maintainers try to "upperhand" contributors, because they see the contribution as something deliberately undertaken to benefit the person who is e.g. submitting a bug report. This is a massive shift away from the spirit of the mid-to-late 2000–2010 era characterized by initiatives like Wikipedia (and wikis generally) and essays by Shirky on the adhocracy around the new digital commons.

  4. Aug 2022
    1. The creator of CodeTriage, Richard Schneeman, was surprised to learn one day that the Ruby on Rails core team (of about 7 or so people) were responsible for handling ALL the issues opened on the Rails GitHub repo. At the time, there were about 700 or so issues. These maintainers are hugely valuable to the project due to their depth of knowledge, however keeping up with issues was taking a huge amount of time. Would you rather these highly specialized maintainers spend their time developing new features and actually fix bugs, or would you want them to spend their days responding to hundreds of issues? Asking for simple questions like "what version of Rails are you using?", and "can you provide an example app?", and "is this fixed on master?”. While asking these questions might only take 5 or 10 minutes of time, the sheer volume of issues per maintainer was unreasonable. This was highlighted by the herculean efforts of another developer Steve Klabnik, who went through every single issue and responded to all of them in a marathon session spanning multiple days. The effort got him accolades and commit access to the Rails repo. While he deserves the praise, the efforts were ultimately unsustainable.

      Surprise: going all in on GitHub—including abandoning traditional practices governing bugtrackers in favor of GitHub's anemic project management tools—has a negative impact.

  5. Jul 2022
    1. it's very easy to measure how many github back and forths people have

      Bad example. The way most GitHub-adjacent subjects are handled and the overheads involved is already evidence that most people are not interested in operational efficiency, let alone measuring it to figure out how to do it better.

  6. May 2022
    1. That people show off these illegible globs in public only makes sense from a signaling perspective: They are saying, “look at how many nodes I have in my brain, amazing nodes

      See also: GitHub contribution graphs

  7. Mar 2022
    1. I can enjoy my hobby in open-source without Github issues becoming a shouting match that spans 200 comments from people who aren't even invested in the codebase
    1. Except it sucks for everybody who's left out.

      Just like GitHub makes things a non-starter today, unless you've bought in to it the way non-technical people bought in to walled gardens like Facebook and excluded everyone else.

    2. While it's true that GitHub has become more accessible to non-programmers than it once was, these folks won't be comfortable making pull requests anytime soon.

      GitHub's accessibility even wrt programmers leaves much to be desired for anyone who was familiar with highly productive workflow before GitHub came along and apparently handicapped everyone's ability to conceive how things could be any better.

  8. Dec 2021
    1. On the Web, the file extension doesn’t really matter

      Not so much "On the Web" as it is "In JavaScript". mjs is an invention of runtimes like NodeJS (and the unending toolchain hell that sprang up around it) to paper over NodeJS's non-standard idiosyncrasies that are entirely the closed loop result of their own doing.

      The fact that this has infected discussion of JS itself is even more reason to despise Node and its ecosystem.

  9. Feb 2019
  10. Nov 2013
    1. Just as it is certain that one leaf is never totally the same as another, so it is certain that the concept "leaf" is formed by arbitrarily discarding these individual differences and by forgetting the distinguishing aspects.

      A 'snowflake' sort of ideal applied to other words... but a valid point. Our language is imperfect, inaccurate, and vague- every time I read through Nietzche I come around to his thought process a little more.