6 ms·

Before you file a github issue, see if you can fix the problem yourself and submit a pull request. You're in the best position to fix the bug - you've reproduce

Before you file a github issue, see if you can fix the problem yourself and submit a pull request. You're in the best position to fix the bug - you've reproduced the problem, you have the correct environment, and you have full source code. If you're unable to fix the problem, it's your duty to provide as much useful information as possible in order for someone else to solve it. Saying something like "it doesn't work with X" is not helpful. Put yourself in the position of the maintainer and provide the information you'd like to see - OS, versions, exact commands to reproduce the issue, sample data - whatever is necessary. And if you've reported an issue, it's your responsibility to follow up and test and prospective solutions and provide feedback. Their time is not less valuable than yours. Remember that open source project owners have done you a favor by giving you access to the code and owe you EXACTLY NOTHING. Complaining free riders are the worst. Give back to the community.

no_protocol 10y ago
> fix the problem yourself and submit a pull request For smaller projects out on GitHub I often see attempts at this that fail. Stuck in "Open" status for years or outright rejected. Maybe the account in control of the canonical repository is no longer active or interested in the project. Maybe that person doesn't understand or agree with the submitted code or asks for more accompanying work. Maybe the submission is under-documented or not even fully understood by the submitter. Each of these types of sticking points can be overcome, but the bottom line is they all take a lot of work from one side or the other. Does anyone have examples to share of open source projects that have very low friction for drive-by contributions while still maintaining quality? Projects with very clear documentation and instructions for contributing? It would be nice to have some models to aspire to.
- hiddentag 10y ago
  Sure, you have to meet the coding guidelines and rules of the project. Many won't accept a drive by pull request without a unit test and documentation for example. 9 times out of 10 the project authors are grateful for the help.
- voltagex_ 10y ago
  GitHub really needs a way to mark a project as abandoned and possibly point to a maintained fork.
  - vacri 10y ago
    Looking at the last commit date is something of a proxy for that.
- PieterH 10y ago
  > Does anyone have examples to share of open source projects that have very low friction for drive-by contributions while still maintaining quality? Projects with very clear documentation and instructions for contributing? Yes, absolutely. Read https://rfc.zeromq.org/spec:42/C4/ https://rfc.zeromq.org/spec:42/C4/. We developed the C4 contract (in the form of an RFC) precisely to teach maintainers how to welcome new contributors while keeping quality high. It took many years to refine this approach. By formalizing it, it becomes really simple for projects to adopt: all you need in your README 'Contributing' section is a license (we recommend MPLv2), a link to this RFC, and later a style guide to ensure consistent code style. The thing about C4 is that it teaches people to make small testable patches, and to trust new contributors. We know from experience that it's users of a project who keep it alive. Original authors and core maintainers burn out, get full time jobs, start new projects. As long as you have users, though, you have potential contributors. Small patches, merged immediately, with reviews and improvements made asynchronously over time. This style is lovely to work with, kills bike shedding (we argue with new patches rather than comments), and reduces the friction in the project to as low as possible. More on optimistic merging: http://hintjens.com/blog:106 http://hintjens.com/blog:106 In terms of friction: we aim to get a patch live on master within a few minutes. If that breaks master, we fix it either with a new patch, or a revert. Anyone can submit a patch, anyone can revert or improve previous patches. You can't merge your own pull requests. We work straight on master so new code is pushed aggressively towards users capable and willing to use it (those who build off master). We use CI heavily to test backwards compatibility, i.e. that existing APIs and protocols haven't broken. There is also a whole theory of how incremental testable patches remove the need for "intelligent design" and thus the dependency on brilliant key individuals. That's another story which I cover in my book "Social Architecture". Free to read online if you want it. Best of all, this process works. We know because we've been using it quietly and successfully in the ZeroMQ community for years. Of all the things I've done in open source, I consider this my most important work, as it solves the really essential problem raised in TFA, which is how to keep open source projects alive over the long term.
  - tbirdz 10y ago
    Thanks Pieter! I've been interested in that optimistic merging idea of yours for a while now, but I've never had the courage to pull the trigger on it anywhere myself. I had a few questions about it though. The process seems to work by moving the code review portion after the merge instead of doing it before the merge. So instead of sitting in a review queue, the code goes live, and if there's any problems the code is removed. I was wondering if this is really that much better from the contributer's POV. Sure it's discouraging if they submit a patch and have it ignored, but it must be even more discouraging to submit a patch, have it accepted, and later have it removed because it wasn't good enough. Also, I know the incremental patch style is the style for OM, but is there any way to do large sweeping changes, other than forking the project or trying to break it into a series of incremental changes? How well does OM scale with number of contributors? Have you any experience with very low numbers of contributors (where I think you could potentially have bad patches sit in the repo for an excessive period until they are removed), or with very, very large numbers of contributors? Really though, all the ZeroMQ RFCs are great. If any of you are doing some C programming, I'd highly recommend checking out ZeroMQ's CLASS C style guide: https://rfc.zeromq.org/spec:21/CLASS https://rfc.zeromq.org/spec:21/CLASS
- watermoose 10y ago
  > For smaller projects out on GitHub I often see attempts at this that fail. Stuck in "Open" status for years or outright rejected. This is why you fork. Some forks even merge branches that were PR'd to the original fork and just start managing their own. This is why GitHub has a "network" graph where you can see the other forks on the timeline and can choose a newer fork if an older one has either been abandoned or is not being upkept or doesn't work with some newer version of X that you need it to work with.
ap22213 10y ago
I hate to say this, but most of the time, I just fork it, fix it, and forget it. That may sound like I'm not being a good community member. But, most of the time, dealing with the maintainers is more effort than I have time for.
- no_protocol 10y ago
  > I just fork it, fix it, and forget it. When you say you like to just fork it, do you mean that you're publishing the fixes you make somewhere, or just keeping them to yourself? I am very interested in any attempts at some kind of fork aggregator (see [0] and [1]) that can help interested parties see what patches have landed in each fork, rather than just which ones have their own users. [0]http://forked.yannick.io/jquery/jquery http://forked.yannick.io/jquery/jquery [1]http://www.toddsifleet.com/projects/github-forks#jquery/jquery http://www.toddsifleet.com/projects/github-forks#jquery/jque...
  - dogma1138 10y ago
    >When you say you like to just fork it, do you mean that you're publishing the fixes you make somewhere, or just keeping them to yourself Really depends, some maintainers and authors really dislike forking, they also tend to be the ones hardest to deal with on pull requests.
  - voltagex_ 10y ago
    Most of my projects are forked by people who never make any changes to the fork. I'm not sure if this is some kind of spam or people trying to make GitHub profiles look better to recruiters.
    - vacri 10y ago
      A fork = code under the user's control. A fork doesn't go away if the original source does.
    - afarrell 10y ago
      These types of forks are asirational guitars bought by people who want to spend the time but never find it.
jrapdx3 10y ago
Sure, OSS can have bugs and I understand authors don't owe me anything. It would be nice if the program can be improved, but I'm certainly not going to demand it. Depending on the software and problem sometimes I can fix it, and when I have fixed it, I'm happy to submit a patch, if there's a reasonably convenient way to do so. I have encountered times when it's more complicated to offer the fix than it was to fix the problem. IMHO, it would be useful to be able to send code and documentation without having to navigate multiple layers of logins, subscriptions, and other hurdles. Sometimes the bug is too obscure for me to find, or requires deep knowledge of hardware/OS interfaces beyond the capacity of mere mortal users. Like patches, bug reports should also be easy and uncomplicated to submit, and to communicate about if necessary. I think many users are sophisticated enough about software in general, and want to help resolve problems. They may not be able to single-handedly debug complex issues but when met halfway by projects these users would probably do a lot more to assist.
ara24 10y ago
An open source project is as good as dead without users. Whether they are complaining or not, if someone gives you a piece of their valuable time, that should be appreciated.
- franlupion 10y ago
  Most open source projects are used by their owners, otherwise they are short lived. Not all of them need, or even should, be used by many.
- ramblenode 10y ago
  Users are only as good for the project as their reinvestment in the project. A small number of users who contribute code, money, or bug reports is better than a large number of users who never interact with the maintainers. In most cases the number of overall users is correlated with the number of contributors, but it's the latter group who are driving development and growth. A large user base is more a side effect of a successful project than a driving force.
  - ara24 10y ago
    may be, you are right, users are as good as their reinvestment, with regards to open source. However, reinvestment doesn't necessarily have to mean code, money, bug reports or something similar. It could be as simple as, spreading the word. I really appreciate those who share their experiences with a project. It helps make long term decisions easier.
zby 10y ago
Another option is to add a failing test.
empthought 10y ago
> it's your duty ... > it's your responsibility ... If open source project owners owe people exactly nothing, then certainly open source project users have neither the duty nor the responsibility to contribute anything back, either.
- Thrillington 10y ago
  The duty and responsibilities given to users are real. If you want help from a project maintainer to fix your submitted issue you have a duty to provide them enough information to solve it. If your project has a dependency on a library it's your responsibility to your own code to make sure that proposed fixes work.
  - empthought 10y ago
    I don't think you understand what a "duty" is. A duty is an ethical and moral requirement. Creating the conditions for someone else to help me most easily is not a duty; it's just common sense.
  - deleted 10y ago
    [deleted]
  - deleted 10y ago
    [deleted]
- hiddentag 10y ago
  The vast majority of open source projects are a volunteer effort. Either you contribute and better the software or support its community, or you don't. But if you choose the latter you can't complain about the software.
  - empthought 10y ago
    I certainly can complain about the software. Obviously everyone else is free to ignore me. Even though I use all of their software, I honestly don't care about the Linux, Java, Node, Emacs, or Python "communities" and it is frankly silly for open source developers to expect me to. I have real communities and responsibilities to devote unpaid labor to.

no_protocol 10y ago

> fix the problem yourself and submit a pull request For smaller projects out on GitHub I often see attempts at this that fail. Stuck in "Open" status for years or outright rejected. Maybe the account in control of the canonical repository is no longer active or interested in the project. Maybe that person doesn't understand or agree with the submitted code or asks for more accompanying work. Maybe the submission is under-documented or not even fully understood by the submitter. Each of these types of sticking points can be overcome, but the bottom line is they all take a lot of work from one side or the other. Does anyone have examples to share of open source projects that have very low friction for drive-by contributions while still maintaining quality? Projects with very clear documentation and instructions for contributing? It would be nice to have some models to aspire to.

hiddentag 10y ago
Sure, you have to meet the coding guidelines and rules of the project. Many won't accept a drive by pull request without a unit test and documentation for example. 9 times out of 10 the project authors are grateful for the help.
voltagex_ 10y ago
GitHub really needs a way to mark a project as abandoned and possibly point to a maintained fork.
- vacri 10y ago
  Looking at the last commit date is something of a proxy for that.
PieterH 10y ago
> Does anyone have examples to share of open source projects that have very low friction for drive-by contributions while still maintaining quality? Projects with very clear documentation and instructions for contributing? Yes, absolutely. Read https://rfc.zeromq.org/spec:42/C4/ https://rfc.zeromq.org/spec:42/C4/. We developed the C4 contract (in the form of an RFC) precisely to teach maintainers how to welcome new contributors while keeping quality high. It took many years to refine this approach. By formalizing it, it becomes really simple for projects to adopt: all you need in your README 'Contributing' section is a license (we recommend MPLv2), a link to this RFC, and later a style guide to ensure consistent code style. The thing about C4 is that it teaches people to make small testable patches, and to trust new contributors. We know from experience that it's users of a project who keep it alive. Original authors and core maintainers burn out, get full time jobs, start new projects. As long as you have users, though, you have potential contributors. Small patches, merged immediately, with reviews and improvements made asynchronously over time. This style is lovely to work with, kills bike shedding (we argue with new patches rather than comments), and reduces the friction in the project to as low as possible. More on optimistic merging: http://hintjens.com/blog:106 http://hintjens.com/blog:106 In terms of friction: we aim to get a patch live on master within a few minutes. If that breaks master, we fix it either with a new patch, or a revert. Anyone can submit a patch, anyone can revert or improve previous patches. You can't merge your own pull requests. We work straight on master so new code is pushed aggressively towards users capable and willing to use it (those who build off master). We use CI heavily to test backwards compatibility, i.e. that existing APIs and protocols haven't broken. There is also a whole theory of how incremental testable patches remove the need for "intelligent design" and thus the dependency on brilliant key individuals. That's another story which I cover in my book "Social Architecture". Free to read online if you want it. Best of all, this process works. We know because we've been using it quietly and successfully in the ZeroMQ community for years. Of all the things I've done in open source, I consider this my most important work, as it solves the really essential problem raised in TFA, which is how to keep open source projects alive over the long term.
- tbirdz 10y ago
  Thanks Pieter! I've been interested in that optimistic merging idea of yours for a while now, but I've never had the courage to pull the trigger on it anywhere myself. I had a few questions about it though. The process seems to work by moving the code review portion after the merge instead of doing it before the merge. So instead of sitting in a review queue, the code goes live, and if there's any problems the code is removed. I was wondering if this is really that much better from the contributer's POV. Sure it's discouraging if they submit a patch and have it ignored, but it must be even more discouraging to submit a patch, have it accepted, and later have it removed because it wasn't good enough. Also, I know the incremental patch style is the style for OM, but is there any way to do large sweeping changes, other than forking the project or trying to break it into a series of incremental changes? How well does OM scale with number of contributors? Have you any experience with very low numbers of contributors (where I think you could potentially have bad patches sit in the repo for an excessive period until they are removed), or with very, very large numbers of contributors? Really though, all the ZeroMQ RFCs are great. If any of you are doing some C programming, I'd highly recommend checking out ZeroMQ's CLASS C style guide: https://rfc.zeromq.org/spec:21/CLASS https://rfc.zeromq.org/spec:21/CLASS
watermoose 10y ago
> For smaller projects out on GitHub I often see attempts at this that fail. Stuck in "Open" status for years or outright rejected. This is why you fork. Some forks even merge branches that were PR'd to the original fork and just start managing their own. This is why GitHub has a "network" graph where you can see the other forks on the timeline and can choose a newer fork if an older one has either been abandoned or is not being upkept or doesn't work with some newer version of X that you need it to work with.

ap22213 10y ago

I hate to say this, but most of the time, I just fork it, fix it, and forget it. That may sound like I'm not being a good community member. But, most of the time, dealing with the maintainers is more effort than I have time for.

no_protocol 10y ago
> I just fork it, fix it, and forget it. When you say you like to just fork it, do you mean that you're publishing the fixes you make somewhere, or just keeping them to yourself? I am very interested in any attempts at some kind of fork aggregator (see [0] and [1]) that can help interested parties see what patches have landed in each fork, rather than just which ones have their own users. [0]http://forked.yannick.io/jquery/jquery http://forked.yannick.io/jquery/jquery [1]http://www.toddsifleet.com/projects/github-forks#jquery/jquery http://www.toddsifleet.com/projects/github-forks#jquery/jque...
- dogma1138 10y ago
  >When you say you like to just fork it, do you mean that you're publishing the fixes you make somewhere, or just keeping them to yourself Really depends, some maintainers and authors really dislike forking, they also tend to be the ones hardest to deal with on pull requests.
- voltagex_ 10y ago
  Most of my projects are forked by people who never make any changes to the fork. I'm not sure if this is some kind of spam or people trying to make GitHub profiles look better to recruiters.
  - vacri 10y ago
    A fork = code under the user's control. A fork doesn't go away if the original source does.
  - afarrell 10y ago
    These types of forks are asirational guitars bought by people who want to spend the time but never find it.

jrapdx3 10y ago

Sure, OSS can have bugs and I understand authors don't owe me anything. It would be nice if the program can be improved, but I'm certainly not going to demand it. Depending on the software and problem sometimes I can fix it, and when I have fixed it, I'm happy to submit a patch, if there's a reasonably convenient way to do so. I have encountered times when it's more complicated to offer the fix than it was to fix the problem. IMHO, it would be useful to be able to send code and documentation without having to navigate multiple layers of logins, subscriptions, and other hurdles. Sometimes the bug is too obscure for me to find, or requires deep knowledge of hardware/OS interfaces beyond the capacity of mere mortal users. Like patches, bug reports should also be easy and uncomplicated to submit, and to communicate about if necessary. I think many users are sophisticated enough about software in general, and want to help resolve problems. They may not be able to single-handedly debug complex issues but when met halfway by projects these users would probably do a lot more to assist.

ara24 10y ago

An open source project is as good as dead without users. Whether they are complaining or not, if someone gives you a piece of their valuable time, that should be appreciated.

franlupion 10y ago
Most open source projects are used by their owners, otherwise they are short lived. Not all of them need, or even should, be used by many.
ramblenode 10y ago
Users are only as good for the project as their reinvestment in the project. A small number of users who contribute code, money, or bug reports is better than a large number of users who never interact with the maintainers. In most cases the number of overall users is correlated with the number of contributors, but it's the latter group who are driving development and growth. A large user base is more a side effect of a successful project than a driving force.
- ara24 10y ago
  may be, you are right, users are as good as their reinvestment, with regards to open source. However, reinvestment doesn't necessarily have to mean code, money, bug reports or something similar. It could be as simple as, spreading the word. I really appreciate those who share their experiences with a project. It helps make long term decisions easier.

zby 10y ago

Another option is to add a failing test.

empthought 10y ago

> it's your duty ... > it's your responsibility ... If open source project owners owe people exactly nothing, then certainly open source project users have neither the duty nor the responsibility to contribute anything back, either.

Thrillington 10y ago
The duty and responsibilities given to users are real. If you want help from a project maintainer to fix your submitted issue you have a duty to provide them enough information to solve it. If your project has a dependency on a library it's your responsibility to your own code to make sure that proposed fixes work.
- empthought 10y ago
  I don't think you understand what a "duty" is. A duty is an ethical and moral requirement. Creating the conditions for someone else to help me most easily is not a duty; it's just common sense.
- deleted 10y ago
  [deleted]
- deleted 10y ago
  [deleted]
hiddentag 10y ago
The vast majority of open source projects are a volunteer effort. Either you contribute and better the software or support its community, or you don't. But if you choose the latter you can't complain about the software.
- empthought 10y ago
  I certainly can complain about the software. Obviously everyone else is free to ignore me. Even though I use all of their software, I honestly don't care about the Linux, Java, Node, Emacs, or Python "communities" and it is frankly silly for open source developers to expect me to. I have real communities and responsibilities to devote unpaid labor to.