4 ms·

It's not hard, just suck it up and register for the ML, and prepare the patches. People are irrationally scared of this process. There are plentiful guides.

mdaniel 8y ago
It's not always that it's hard, rather it can be demoralizing to have the same experience that @S-E-P did [a sibling comment to yours] where you _do_ expend the energy and then patches sit unactioned for months or years
- Sir_Cmpwn 8y ago
  Your patches are your responsibility. Bump them, reach out to maintainers directly, etc. Manual improvements are easy to review once you can get someone to.
  - oblio 8y ago
    Or I could just do what 99% of devs do, not give a crap and try StackOverflow/blogs to find an answer... That was my whole point, higher friction => much fewer contributions.
    - Sir_Cmpwn 8y ago
      Higher friction => higher quality contributions.
      - aktau 8y ago
        But also fewer contributions, I reckon. If someone wants to contribute something big, they'll jump through all the hoops. But if all one wants is to contribute another example to a man page, I'd wager they're more easily discouraged by an arcane setup process. GitHub solves a lot of this friction by having: 1. One account for manifesting your chosen identity, which you likely already have. 2. One common way of getting the source code and sending diffs/patches (read: PRs). The workflow is quite similar, in the abstract. But GitHub and friends solve important pain points.
        Sir_Cmpwn 8y ago
        1. One account for manifesting your chosen identity, which you likely already have. You also have an email address, so. You need an email address to get a GitHub account, so technically it's harder to set up GitHub. 2. One common way of getting the source code and sending diffs/patches (read: PRs). This is built into git. Don't need GitHub for either.
        aktau 8y ago
        It looks like you think that older approaches to open-source collaboration (like many of the GNU projects are using) are more or less as user-friendly as GitHub. I don't have the data to prove that they aren't, just an intuition. Perhaps the last argument I have is that I've heard a number of times about moving a project to GitHub (for example: the Go language or Vim the editor), but decidedly less often one hears of projects moving away from GitHub towards older forms (such as the wonderfully documented https://gcc.gnu.org/contribute.html https://gcc.gnu.org/contribute.html). Despite the great documentation, I'm somehow not drawn to hacking on it to fix a small glitch, due to the overhead that entails. Mind, some of that overhead would be incurred just once, as it is general to the mailing list approach to collaboration. That, I believe, is another advantage of a project being on GitHub: for almost all projects there's a standard way of sending your patch: make a pull request. About your counterpoints: 1. True. I was thinking of the bug trackers many mailing-list oriented projects have, which often require creating accounts just to file a bug. 2. I was more referring to things like (1) where to find the clone URL and (2) how to send a patch (the make a PR button is always the same). Removing friction (even small frictions) will enable fishing for the long tail of small fixes. On the other side, I do not believe large contributions are greatly affected by the differences between these systems.
kitsunesoba 8y ago
I don’t think being afraid of the process is the problem. It’s more about how unnecessarily manual the process is paired with the possibility of your patch’s email thread getting buried never to be seen again or worse, its reviewer abandoning it halfway through the review process with no easy way for someone else to pick it up. That’s not to say that Github pull requests and the like are perfect (far from it) but it’s undeniable that they smooth the process quite considerably and make contribution far more accessible.
- Sir_Cmpwn 8y ago
  People are busy. If you want your patch considered, you should be bumping it and reaching out to people who can merge it. Man page improvements are generally a shoe-in, just get someone to pay attention to it for a few minutes and it'll get in.
  - mikebenfield 8y ago
    The process you're describing in this comment is exactly the outdated approach people are saying they don't want to do.
    - Sir_Cmpwn 8y ago
      It's not like this isn't a problem for GitHub, either. Pull requests go ignored, too.

mdaniel 8y ago

It's not always that it's hard, rather it can be demoralizing to have the same experience that @S-E-P did [a sibling comment to yours] where you _do_ expend the energy and then patches sit unactioned for months or years

Sir_Cmpwn 8y ago
Your patches are your responsibility. Bump them, reach out to maintainers directly, etc. Manual improvements are easy to review once you can get someone to.
- oblio 8y ago
  Or I could just do what 99% of devs do, not give a crap and try StackOverflow/blogs to find an answer... That was my whole point, higher friction => much fewer contributions.
  - Sir_Cmpwn 8y ago
    Higher friction => higher quality contributions.
    - aktau 8y ago
      But also fewer contributions, I reckon. If someone wants to contribute something big, they'll jump through all the hoops. But if all one wants is to contribute another example to a man page, I'd wager they're more easily discouraged by an arcane setup process. GitHub solves a lot of this friction by having: 1. One account for manifesting your chosen identity, which you likely already have. 2. One common way of getting the source code and sending diffs/patches (read: PRs). The workflow is quite similar, in the abstract. But GitHub and friends solve important pain points.
      - Sir_Cmpwn 8y ago
        1. One account for manifesting your chosen identity, which you likely already have. You also have an email address, so. You need an email address to get a GitHub account, so technically it's harder to set up GitHub. 2. One common way of getting the source code and sending diffs/patches (read: PRs). This is built into git. Don't need GitHub for either.
        aktau 8y ago
        It looks like you think that older approaches to open-source collaboration (like many of the GNU projects are using) are more or less as user-friendly as GitHub. I don't have the data to prove that they aren't, just an intuition. Perhaps the last argument I have is that I've heard a number of times about moving a project to GitHub (for example: the Go language or Vim the editor), but decidedly less often one hears of projects moving away from GitHub towards older forms (such as the wonderfully documented https://gcc.gnu.org/contribute.html https://gcc.gnu.org/contribute.html). Despite the great documentation, I'm somehow not drawn to hacking on it to fix a small glitch, due to the overhead that entails. Mind, some of that overhead would be incurred just once, as it is general to the mailing list approach to collaboration. That, I believe, is another advantage of a project being on GitHub: for almost all projects there's a standard way of sending your patch: make a pull request. About your counterpoints: 1. True. I was thinking of the bug trackers many mailing-list oriented projects have, which often require creating accounts just to file a bug. 2. I was more referring to things like (1) where to find the clone URL and (2) how to send a patch (the make a PR button is always the same). Removing friction (even small frictions) will enable fishing for the long tail of small fixes. On the other side, I do not believe large contributions are greatly affected by the differences between these systems.

kitsunesoba 8y ago

I don’t think being afraid of the process is the problem. It’s more about how unnecessarily manual the process is paired with the possibility of your patch’s email thread getting buried never to be seen again or worse, its reviewer abandoning it halfway through the review process with no easy way for someone else to pick it up. That’s not to say that Github pull requests and the like are perfect (far from it) but it’s undeniable that they smooth the process quite considerably and make contribution far more accessible.

Sir_Cmpwn 8y ago
People are busy. If you want your patch considered, you should be bumping it and reaching out to people who can merge it. Man page improvements are generally a shoe-in, just get someone to pay attention to it for a few minutes and it'll get in.
- mikebenfield 8y ago
  The process you're describing in this comment is exactly the outdated approach people are saying they don't want to do.
  - Sir_Cmpwn 8y ago
    It's not like this isn't a problem for GitHub, either. Pull requests go ignored, too.