4 ms·

The first thing you should always do is create a ticket. There you can discuss if its worth spending time on a patch and what the best implementation could be.

The first thing you should always do is create a ticket. There you can discuss if its worth spending time on a patch and what the best implementation could be. Pull requests that come up out of nowhere usually end up in the end of maintainers' queue. Or you can continue calling people who maintain free and open source projects in their spare time douchebags and neckbeards.

sciurus 14y ago
I cam here to say this. If something is going to take you more than 15 minutes to do, it's better to coordinate it with the project maintainers first. If it takes you less than 15 minutes, you didn't invest enough to be bitter if your code isn't accepted.
- zr52002 14y ago
  Or you can do that, proposing a trivial enhancement, and have 1) The maintainer tell you "that isn't the designed behavior" (no kidding it doesn't do that now, that's why I want to enhance it!) 2) It marked it as a duplicate of the last handful of people that wanted similar features 3) The ticket closed I'm looking at you, jquery-ui
  - akavel 14y ago
    ad.1: "Every program attempts to expand until it can read mail." :) The argument that the dev doesn't want particular functionality can be perfectly reasonable, and might be a sign that he's even a good one and consciously fights to avoid software bloat...
karlshea 14y ago
Or you can be like OpenLayers and just ignore a ticket with almost a dozen comments and two working patches and a pull request! Sometimes people just don't want your code.
- desfrenes 14y ago
  Or you can be like Zend Framework and just ignore a ticket with a working patch and then months later have someone else to win a tee-shirt because that someone who has write access to the repository just participate to a bug hunt. Sometimes people want your code. They just don't want you.
j-kidd 14y ago
Personally, I think ticket description is more important than code, so I always create a ticket first. Unfortunately, github's issue tracker doesn't allow attachment, and thus it inadvertently promotes this "pull requests from out of nowhere" behavior. Call me old fashioned, but I still like ticket + attached patches way more than anything else. Recently, I stumbled upon a Google Code project with several defect issues. One guy commented on each of the issue with a link to his github fork which he has applied the fixes. I clicked the link, and found that the fork has been deleted. What a waste.
- arantius 14y ago
  > github's issue tracker doesn't allow attachment, and thus it inadvertently promotes this "pull requests from out of nowhere" behavior. "Refs #XXX" in the description (PR or any commit) ?

sciurus 14y ago

I cam here to say this. If something is going to take you more than 15 minutes to do, it's better to coordinate it with the project maintainers first. If it takes you less than 15 minutes, you didn't invest enough to be bitter if your code isn't accepted.

zr52002 14y ago
Or you can do that, proposing a trivial enhancement, and have 1) The maintainer tell you "that isn't the designed behavior" (no kidding it doesn't do that now, that's why I want to enhance it!) 2) It marked it as a duplicate of the last handful of people that wanted similar features 3) The ticket closed I'm looking at you, jquery-ui
- akavel 14y ago
  ad.1: "Every program attempts to expand until it can read mail." :) The argument that the dev doesn't want particular functionality can be perfectly reasonable, and might be a sign that he's even a good one and consciously fights to avoid software bloat...

karlshea 14y ago

Or you can be like OpenLayers and just ignore a ticket with almost a dozen comments and two working patches and a pull request! Sometimes people just don't want your code.

desfrenes 14y ago
Or you can be like Zend Framework and just ignore a ticket with a working patch and then months later have someone else to win a tee-shirt because that someone who has write access to the repository just participate to a bug hunt. Sometimes people want your code. They just don't want you.

j-kidd 14y ago

Personally, I think ticket description is more important than code, so I always create a ticket first. Unfortunately, github's issue tracker doesn't allow attachment, and thus it inadvertently promotes this "pull requests from out of nowhere" behavior. Call me old fashioned, but I still like ticket + attached patches way more than anything else. Recently, I stumbled upon a Google Code project with several defect issues. One guy commented on each of the issue with a link to his github fork which he has applied the fixes. I clicked the link, and found that the fork has been deleted. What a waste.

arantius 14y ago
> github's issue tracker doesn't allow attachment, and thus it inadvertently promotes this "pull requests from out of nowhere" behavior. "Refs #XXX" in the description (PR or any commit) ?