15 Matching Annotations
  1. Mar 2021
  2. Feb 2021
    1. When your digital news feed doesn’t contain links, when it cannot be linked to, when it can’t be indexed, when you can’t copy a paragraph and paste it into another application: when this happens your news feed is not flawed or backwards looking or frustrating. It is broken.

      If your news feed doesn't contain links, can't be linked to, indexed, or copied and pasted, it is broken.

      How can this be tied into the five R's of Open Education Resources: Retain, Reuse, Revise, Remix and/or Redistribute content (and perhaps my Revise/Request update ideas: https://boffosocko.com/2018/08/30/the-sixth-r-of-open-educational-resources-oer/)

  3. Dec 2020
    1. You can afford to make a proper PR to upstream.
    2. No more waiting around for pull requests to be merged and published. No more forking repos just to fix that one tiny thing preventing your app from working.

      This could be both good and bad.

      potential downside: If people only fix things locally, then they may be less inclined/likely to actually/also submit a merge request, and therefore it may be less likely that this actually (ever) gets fixed upstream. Which is kind of ironic, considering the stated goal "No more waiting around for pull requests to be merged and published." But if this obviates the need to create a pull request (does it), then this could backfire / work against that goal.

      Requiring someone to fork a repo and push up a fix commit -- although a little extra work compared to just fixing locally -- is actually a good thing overall, for the community/ecosystem.

      Ah, good, I see they touched on some of these points in the sections:

      • Benefits of patching over forking
      • When to fork instead
    1. Better community building: At the moment, MDN content edits are published instantly, and then reverted if they are not suitable. This is really bad for community relations. With a PR model, we can review edits and provide feedback, actually having conversations with contributors, building relationships with them, and helping them learn.
    2. Better contribution workflow: We will be using GitHub’s contribution tools and features, essentially moving MDN from a Wiki model to a pull request (PR) model. This is so much better for contribution, allowing for intelligent linting, mass edits, and inclusion of MDN docs in whatever workflows you want to add it to (you can edit MDN source files directly in your favorite code editor).
  4. Oct 2020
  5. Aug 2020
    1. The collection of changes to fix the issues we want to address would be probably of the same size, but it would make easier to review and merge if we could break this PR in many steps. I find it really hard to believe we need to change 170 lines in a single commit to be able to fix this issue. We probably could break the first commit in many commits, test the class better and that would give more confidence over what is being changed. Right now I see a huge diff, with a few assertions changes and no real reason why all those lines had to change.
  6. Mar 2015