3 ms·
I've made a bunch of one line PRs that I'm worried are perceived like this, but they're always a fix for something that cost me a lot of time. Examples include
by strken 7y ago
I've made a bunch of one line PRs that I'm worried are perceived like this, but they're always a fix for something that cost me a lot of time. Examples include adding quotes around CSS base64 URLs (our base64 string included //) and changing the case of some headers in documentation (headers were downcased upstream and the example in the doc failed silently). Are these the kind of PRs you don't like?
- paxys 7y agoNot at all. It isn't the size of the PR that matters, but I generally want contributors to: - Discuss their changes beforehand (usually on the issue page) - Use patterns and practices that the rest of the codebase follows - Listen to comments and feedback - Write tests While the work is "free", it should still be treated professionally.
- bcrosby95 7y ago> - Discuss their changes beforehand (usually on the issue page) Interesting. When I last looked at contributing to open source, some general advice was to offer up code even if its likely the wrong approach. The idea being that maintainers are busy, and there's lots of people that drag on their time without ever contributing anything. Showing you're actually willing to put in time and effort will make the maintainer more likely to guide you in the correct direction because you've already shown you're willing to spend time on the issue.
- aesyondu 7y agoI feel the same way. Although I have only been starting to contribute recently, I thought that by offering code first via pull request I wouldn't be perceived as a whiner in the issues section.
- atq2119 7y agoThis is definitely true. I'm not a fan of Issues discussion with random people who are not known to be reliable contributors. Talk is cheap, show me the code.