20 Matching Annotations
- Jan 2023
-
-
This will no longer be necessary if this MR is merged #101
-
-
github.com github.com
-
If this MR had been merged it would have saved us a lot of time and trouble.
-
- Sep 2022
-
github.com github.com
-
let's not mix code changes with prettier. This is a bad practise which complicates code review and history review. Let's apply prettier in a separate PR/commit.
-
- Aug 2022
-
-
Formalize your Pull Request etiquette.
Tags
Annotators
URL
-
- May 2021
-
github.com github.com
-
No it doesn't. I've simply told SvelteKit to ignore the type error from credentials missing. If there's some other issue or missing feature it's not blocked by this. That being said, I wouldn't mind getting this change in
-
- Mar 2021
-
www.chevtek.io www.chevtek.io
-
Sure sometimes my changes get rejected, but it almost always comes with a reason why and I can work together with the maintainer to come up with a sensible solution to my issue.
-
- Feb 2021
-
github.com github.com
-
Any idea @AaronLasseigne if this is mergeable?
-
-
github.com github.com
-
Take 3, Previously attempted in 2012 (#8189) and 2015 (#19709). This new version uses ActiveModel Attributes API.
-
-
stevenberlinjohnson.com stevenberlinjohnson.com
-
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/)
-
- Dec 2020
-
www.npmjs.com www.npmjs.com
-
You can afford to make a proper PR to upstream.
-
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
Tags
- limited time: not right now (maybe later)
- irony
- maintaining a fork while waiting for upstream to merge
- pull request stalled
- doing it right/properly
- when to _
- taking the time to do it right/properly
- proper
- making it easy to do the wrong thing
- forking to add a desired missing feature/change
- forking (patching vs. forking)
- pull request
Annotators
URL
-
-
github.com github.com
-
Can this be merged please, this fixes a problem I have
-
-
hacks.mozilla.org hacks.mozilla.org
-
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.
-
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).
Tags
- community relations
- contribution workflow
- community building
- advantages/merits/pros
- helping others to learn
- wiki model
- reverting a previous decision/change/commit
- reverting: creates negative experience
- efficiency (human efficiency)
- helping others
- opportunity to improve/fix something
- relationship (people)
- online community
- community (for a project or product)
- open source community
- pull request workflow
- receiving feedback
- encouraging feedback
- flexibility to use the tool that you prefer
- opportunity
- software preferences are personal
Annotators
URL
-
- Oct 2020
-
-
But maybe this PR should still be merged until he finds time for that?
-
Sorry this sat for so long!
Tags
- open-source software: progress seems slow
- pull request stalled
- iterative process
- waiting for maintainers to review / merge pull request / give feedback
- big change/rewrite vs. continuous improvements / smaller refactorings
- don't let big plans/goals get in the way of integrating/releasing smaller changes/improvements
- not a blocker (issue dependency)
Annotators
URL
-
- Aug 2020
-
github.com github.com
-
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.
-
- Mar 2015
-
piratenpad.de piratenpad.depdf1
-
n
werden ... werfen
oder
wenden, dann aber ohne werfen.
Tags
Annotators
URL
-
-
calmtechnology.com calmtechnology.com
-
are
to be deleted
-