7 Matching Annotations
  1. Dec 2022
    1. It’s fairly clear now that the current catalog process is too heavyweight. I hope we can move to a lighter workflow in the future that feels more like editing a wiki.
  2. Aug 2022
    1. "Why have a locked wiki when you can instead just post static Web pages?"

      What even is a locked wiki insofar as the ways it differs from traditional (pre-wiki) content publishing pipelines? Where's the wiki part of it?

  3. Jul 2022
    1. To make a page on MySpace, all it took was text in a textbox.The text could be words or code.Anyone could read the words and see the code.
  4. Apr 2022
    1. To drive this point home:

      I sometimes get people who balk at my characterization of GitHub-style anti-wikis as being inferior to, you know, actual wikis. "You can just use the GitHub UI to edit the files", they'll sometimes say.

      A case study: a couple days ago, I noticed that the lone link in the current README for Jeff Zucker's solid-rest project is a 404. I made a note of it. Just now, I reset my GitLab password, logged in to solid/chat, and notified Jeff https://gitter.im/solid/chat?at=611976c009a1c273827b3bd1. Jeff's response was, "I'll change it".

      This case is rich with examples of what makes unwikis so goddamn inefficient to work with. First, my thought upon finding the broken link was to take note of it (i.e. so that it can eventually be taken care of) rather than fixing it immediately, as would have been the case with a wiki. More on this in a bit. Secondly, my eventual action was still not something that directly addressed the problem—it was to notify someone else† of the problem so that it might be fixed by them, due to the unwiki nature of piles of Git-managed markdown. Thirdly, even Jeff's reflex is not to immediately change it—much like my reaction, his is to note the need for a fix himself and then to tell me he's going to change it, which he will presumably eventually do. Tons of rigamarole just to get a link fixed‡ that remains broken even after having gone through all this.

      † Any attempt to point the finger at me here (i.e. coming up short from having taken the wrong action—notifying somebody rather than doing it myself) would be getting it wrong. First, the fact that I can't just make an edit without taking into account the myriad privacy issues that GitHub presents is materially relevant! Secondly, even if I had been willing to ignore that thorn (or jump through the necessary hoops to work around it) and had used the GitHub web UI as prescribed, it still would have ended up as a request for someone else to actually take action on, because I don't control the project.

      ‡ Any attempt to quibble here that I'm talking about changing a README and not (what GitHub considers) a wiki page gets it wrong. We're here precisely because GitHub's unwikis are a bunch of files of markdown. The experience of changing an unwiki page would be rife with the same problems as encountered here.

    1. Yes, the website itself is a project that welcomes contributions. If you’d like to add information, fix errors, or make improvements (especially to the visual design), talk to @ivanreese in the Slack or open a PR.

      Contribution: make it a wiki. (An actual wiki, not GitHub-style anti-wikis.)

    1. Each entry is a Markdown file stored in the _pages directory.

      Nah, dude. That's not a wiki.

  5. Mar 2022
    1. There are way too many dipshits who are way too happy to come out of the woodwork when this topic is brought up to try to drop an FYI wisdom nugget on you about how github.com will let you skip a few of these steps and do the edit/commit thing directly in your browser. Great job on almost entirely missing the point, morons. Let's be excruciatingly clear:

      If, at any point, "submit a PR" comes up during an explanation of how to do a run-of-the-mill edit on your project's wiki, then your project does not have a wiki.