TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

A plea for better open source etiquette

103 点作者 benilov大约 12 年前

17 条评论

relix大约 12 年前
I once submitted a pull request to add a feature to a popular OSS library. It got several "thumbs up", was actually useful, didn't change the API and had test coverage. I put a lot of time into making it nice and clean, in my opinion a perfect pull request. Two years later they closed it with a comment saying one of the more senior contributors added code that did what my code did (except 2 years later) so mine wasn't necessary anymore. They never merged my changes.<p>Objectively I can say what they did was cold but logical in the end, since it incorporated the change better into how they saw the next version of the library and they can trust the more senior contributor more. Subjectively it really hurt. It was one of my first contributions to open source and it definitely unmotivated me to do any others. It was in limbo for 2 years until they finally implemented it in another way, instead of just accepting the pull request for now until they could change it.<p>I don't hold a grudge against the people involved since I've used their code a lot and am thankful for their indirect help using their libraries. It just felt shitty.
评论 #5547400 未加载
评论 #5548113 未加载
TimCinel大约 12 年前
Gulp. I'm guilty of this. An iOS component I shared became quite popular.<p>Now I don't even do iOS development anymore, Xcode is out of date, I haven't even used ARC. Whenever people poke me, saying that the issues and PRs are piling up, I tell them my situation and ask what they suggest I do. Surprisingly, my responses get no response.<p>Perhaps I should just add some of the past contributors to the commit access list.
评论 #5546000 未加载
评论 #5546787 未加载
评论 #5546010 未加载
JangoSteve大约 12 年前
I'm an open-source maintainer who doesn't always answer issues and pull-requests right away. It sucks, I'm trying to get better. I can understand the frustration, but these sort of posts (or pleas or whatever you want to call them) always lack any sort of acknowledgement of the possibility that some maintainer's life may be different than yours.<p>&#62; You could always have the courtesy to acknowledge the bug or PR I’ve submitted.<p>The thing is, you're actually implying more than you're saying. What you really mean is, "You could always have the courtesy to acknowledge the bug or PR I’ve submitted <i>as soon as I submit it</i>." You mention all the things you've done by the time you've submitted the ticket on Github, and I can appreciate all of that (I even wrote an entire article espousing your side [1]). The thing is, you did all that on your own time, on your own schedule. You're asking the maintainer of the open source project to help you finish solving your problem right when you submitted the ticket, i.e. on your schedule, with no acknowledgement for theirs.<p>To you, it might not seem like much to ask, for the maintainer to drop what they're doing to respond to your request. But some open source maintainers are very busy. They may get between 100 and 200 emails a day during the week. The Github notification from your submission is one of them. They may own a company, with employees to whom they are responsible. And they may manage many different projects, including several open-source projects. Even if it only takes 20 seconds to physically comment on your issue or pull request, it still requires a mental context switch, which they may not have time for that day, or even that week.<p>Furthermore, to be frank, it's often the sense of entitlement and lack of understanding that makes it unenjoyable to respond to requests. Granted, not all contributors feel entitled, but even having to deal with one entitled person is enough to destroy your motivation for the rest of the day. Imagine that you've spent years on some project, and fixed a hundred issues submitted by users, and helped many contributors get their pull requests merged. And now imagine the 101st ticket is someone who comes along and says, "All the time and hard work you've put into this project and provided for anyone to use free of charge is not enough; you're a disappointment because you don't respond fast enough." It's exhausting.<p>"If you don't have time to maintain the project, then mark the project as not actively maintained so we can move on," you say. But it doesn't quite work like that. It's not that the project isn't maintained. The maintainer may just be really busy this month. Or maybe they've been really busy for 6 months. They're still maintaining it, they just might not have time to look at things for a little while. Labeling the project as "unmaintained" would be short-changing all the people who are still actively using and developing and maintaining it.<p>"But my change is really small, just merge it in," you say. The problem is, you don't really have the context to make that claim with 100% certainty. You're not the one who has to deal with all the issue that may come rolling in due to some unintended and unforeseen consequence of your change. Also, if there are a hundreds or thousands or tens of thousands of people using the project without a problem, and you're the first person to report an issue, chances are your issue is not that urgent. That means, even for a simple patch, the maintainer has to weigh benefits of the patch with the potential that it breaks stuff for other users. The only "small patch" is one that changes a comment in the code. If you're changing an actual line of code, the maintainer rarely sees it as "small".<p>I don't type all this to make excuses. Like I said at the beginning, I understand the frustration. I'm not just a maintainer, I'm also a user of other open source projects, so I know. Uncertainty sucks. This is an area I'm trying to get better about myself as a maintainer. I even considered not submitting this comment, for fear of anyone misunderstanding or taking this the wrong way, and the inevitable "open source is a responsibility" responses. But I decided to submit it anyway, in case it helps anyone who truly wonders what the hell is going on, on the other side of that pull request.<p>[1] <a href="http://www.alfajango.com/blog/communicating-with-engineers-and-contributing-to-open-source/" rel="nofollow">http://www.alfajango.com/blog/communicating-with-engineers-a...</a>
评论 #5546234 未加载
评论 #5546245 未加载
评论 #5549357 未加载
评论 #5546306 未加载
评论 #5547301 未加载
chris_wot大约 12 年前
The LibreOffice guys are <i>particularly</i> good about code reviews and accepting patches. In fact, they use gerrit (<a href="http://gerrit.libreoffice.org" rel="nofollow">http://gerrit.libreoffice.org</a>), and I'd have to say that one piece of infrastructure has increased contributor patches exponentially.
qwerta大约 12 年前
There is only one answer to this:<p>I would be very happy to review and merge your pull request. I charge by day and my daily fee is 600 euro. Bank details are bellow, once payment is cleared we may proceed :-)<p>Now seriously: Every minute I spend on my OS project I have to cut from my sleep or from time with my family. I would love to review patches, have a chat and perhaps get a free beer, but it is simply not possible.<p>For project maintainers there is simple way to avoid this overload. You need to 'manage your community growth'. If it grows too fast you will be flooded with bug reports, pull requests and emails.<p>For my project I have not provided build system and binary builds for a long time. Users were forced to use IDE and study the code. Also I did not provided any documentation, just a code examples. Key is to attract people with coding skills, who can actually grog code.<p>Also be careful how you advertise your project. You should actually target co-developers (with commit access) instead of users. For example if your project is written in Coffeecript, you should avoid using word 'javascript' on front page and in readme.<p>Sure it hurts number of users in short term. On long run it increased number of power users who do bug triage and answer support questions. The key is to grow number of co-developers together with number of users.
stormbrew大约 12 年前
An interesting pattern I've come across lately is a project where contributions are almost universally either rejected or rewritten (largely superficially) by the original author of the project. I think I dislike this far more than a lack of response, though I've experienced that as well.
评论 #5546565 未加载
leeoniya大约 12 年前
i've submitted some non-trivial PRs with tests to large projects that are still waiting for any form of acknowledgement after several months while other PRs and new commits are being closed around them. it's definitely annoying. maybe it's a github hellban :)
josephg大约 12 年前
As a maintainer of a project with almost 2000 stars on github, I sway back and forth between being allowing ("Just submit code to get what you want done. We can fix it once its in the repository") and a stickler for details ("I don't want your change until you give me tests.")<p>I really wish I could just give everyone who submits patches commit access and let them at the repository. It would save me time. It would save you time. It would make my project better. And I don't write opensource software because I enjoy being a policeman. I hate it. I hate saying no to real work that solves real problems. Unfortunately, the majority of pull requests are simply bad.<p>- Many do not understand the project's conventions (eg, if my project is written in coffeescript, so your code needs to be in coffeescript too). Example: <a href="https://github.com/josephg/ShareJS/pull/36/files" rel="nofollow">https://github.com/josephg/ShareJS/pull/36/files</a> . After I insisted on the code being ported to coffeescript, several users whinged on the project's mailing list about my language choice.<p>- Most pull requests don't have tests. Submitters usually don't even run the unit tests before submitting, and their pull requests often break the tests we do have. I understand that you don't write tests in your application, but the rules are different in an infrastructure project that many people rely on.<p>- People often have extra modifications in their PR that have nothing to do with the patch. For example, this pull request has good parts near the top and also makes my code uglier riiiight down the bottom in the name of 'optimization'. Quotes because optimization was never run, and the changes didn't actually improve performance. <a href="https://github.com/josephg/Chipmunk-js/pull/15/files" rel="nofollow">https://github.com/josephg/Chipmunk-js/pull/15/files</a><p>- Some bug reports exist only to waste my time and complain about my programming language choices. This is what I was doing instead of triaging your bug. I'm sorry, ok? <a href="https://github.com/josephg/Chipmunk-js/issues/11" rel="nofollow">https://github.com/josephg/Chipmunk-js/issues/11</a><p>I usually err on the side of allowing changes and fixing stuff later, but my projects have suffered for this several times. I've had maintainers accept pull requests that break the unit tests (and leave them broken for weeks). I've had otherwise normal code suddenly sprout extra levels of indentation. I've had mountains of bugs appear, filed against a feature I didn't write, don't understand and I never use, who's author has disappeared. I've been burned enough that I can totally understand maintainers who ignore patches and bug reports.<p>I still love everyone who cares about my projects enough to submit a bug report or takes the time to make a pull request. I need contributors to make good software, but it breaks my heart when nice people submit slightly bad code, and I need to either whinge at you or stop working on my own pet feature to clean up your mess. I'm sorry to everyone who's patches gets ignored, but sometimes I get tired too.<p>In short, its fun to complain about The Man because your precious donation of code is being ignored. But its just as thankless running a project, only we shoulder way more responsibility and burn way more time doing it. If you want me to look at more of your bug reports, help triage my other pending bugs and pull requests. If you want me to stay excited about the project, email me to say how much you like it, and tell me about the cool things you're doing with my code. If you want commit access, ask for it. Finally, if you think you can do a better job running a project, use the fork button and do something about it.
评论 #5546260 未加载
评论 #5549430 未加载
评论 #5549655 未加载
bboyjkang大约 12 年前
More projects should look at and adopt the Web Hypertext Application Technology Working Group (WHATWG) HTML Living Standard page (<a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#scripting-0" rel="nofollow">http://www.whatwg.org/specs/web-apps/current-work/multipage/...</a>).<p>You can see status annotations in the left margins that allow you to go to extended/extra information on each section. If you have comments/questions on a section, you can use the widget at the bottom right (it says "Click the location of the error to select it, then type your message here:") to submit a review comment.
joeblau大约 12 年前
I feel like a lot of these requests, especially in the "For a PR" section are things that only more seasoned developers have an appreciation for. Since OSS runs the gamut from bad-ass-mofos to beginners, I feel like you're going to get under a 50th percentile in most of these areas.<p>I agree that things need work, but sometimes it's hard to get to everything, especially if you're doing it for free in spare time.
评论 #5545831 未加载
jakejake大约 12 年前
I think I tend to be rather obsessive about answering, replying and the occasional PR I tend to be really excited about. However I almost always want to tweak the PRs and I don't always have time. I have been guilty of letting some go for a few months, but I did acknowledge and discuss them right away.
pixelcort大约 12 年前
One of the easiest etiquette techniques projects can adopt is to only have the person who opened a ticket close it, in both cases where a fix was applied or it was decided not to fix.<p>This lets the originator of the ticket verify that the issue has been resolved or that there is no issue in the first place.<p><i>Edit:</i> clarification
评论 #5548121 未加载
bsimpson大约 12 年前
Everyone I've ever tried to send a PR to had been very responsive. The rauth guys (litl) are great. I added some AppEngine docs for Line Profiler and I think they got pulled the next day.
pbreit大约 12 年前
More important etiquette: don't make such demands and complaints on maintainers. Incorporating other people's code into a project can be tedious, risky and unrewarding.
rachelbaker大约 12 年前
Z
andyzweb大约 12 年前
We don't want bug fixes with your whining
评论 #5546157 未加载
_pmf_大约 12 年前
It's not the job of open source maintainer to acknowledge every nitpicky little turd (like the mentioned documentation typos) that some guy found.
评论 #5549659 未加载
评论 #5548134 未加载