4 ms·

Bars are lowered, barriers are removed; lowering barriers is a mixed metaphor that doesn't really work because "lowering a barrier" often, in reality, means tha

Bars are lowered, barriers are removed; lowering barriers is a mixed metaphor that doesn't really work because "lowering a barrier" often, in reality, means that a barrier has been put in place. Plus the metaphor has to mean the same thing in this case — there is a barrier to entry, but it is not as difficult to get past as it was previously, which exactly the same as lowering the bar (the bar is still there, it's just lower and therefore easier to jump over)

johnisgood 8y ago
Easier to jump over, which means that people who otherwise wouldn't have been able to pass, now can easily jump over. It reduces quality, doesn't it? What I meant was that due to eliminated barriers, you may get lower quality. I emphasize may here. Just in case.
- geofft 8y ago
  Only if a) the bar(rier) is correlated with quality and b) there are no other quality gates elsewhere in the process.
  - johnisgood 8y ago
    So does anyone know if in this exact situation it is, or it is not, or are we all just assuming that it's necessary a good thing and bash on anyone who dares to bring it up that it may not be the case? I said "arguably", and yes, while I did not provide an argument, I thought someone else could.
    - geofft 8y ago
      Arguably, Nick Cameron is an agent of the Knights Templar and Cargo is a secret plan towards world domination. You need to say why you think things are plausible. (In this exact situation I do know that there's a quality gate later in the process, and it would be very easy for you to determine that too with at most five minutes of research.)
      - johnisgood 8y ago
        I know what you are trying to say. Personally I would like to hear convincing reasons why lowering barriers to contribution is inherently a good thing, in all cases. I mentioned a few cases later on where it might not be favorable, to me, at least. And again: it was just a way to get the attention of people who might agree with it, to hear their side. Or to start/stimulate a discussion. I don't like to just believe things because it sounds good and because it has been repeatedly said to be good, without explaining why. The point was to question it, or come up with scenarios where it is not favorable. Do you agree that such scenarios exist where it is not a good thing, or not?
- captainbland 8y ago
  We have code reviews and stuff for this. It's also totally possible for somebody to spend hours setting something up and then develop really bad code - it might even be more likely in situations where time is a constraint. Having people jump through arbitrary hoops that have nothing to do with the matter at hand is not a good thing. This is especially the case with rust which isn't exactly the most beginner friendly language to begin with.
  - johnisgood 8y ago
    Code reviews, yes. Not all projects can afford to go through millions of contributions because the barrier was lowered or eliminated. So in that case it is not necessary a good thing to accept lazy contributions.[1] And before someone misinterprets, sure, you can work endless hours on a contribution and then submit it easily. This is not the case I am talking about, and this is not what we have observed in the case of these package managers either. Or at least that's what I did when I took a look at npm. If it's not polluted because anyone can submit their garbage easily, then what is at fault, exactly? [1] We are still talking about a package manager, and this project specifically.
    - captainbland 8y ago
      I think that as a package maintainer, you can set the bar(rier) as high or as non-existent as you like. If you've got a lot of contributors, you've almost certainly got some regular contributors who you'd be able to trust to review/triage things for you. Otherwise just stick a big note saying 'we're full up, not accepting PRs, find another project, file or support a bug, the princess is in another castle' on your readme. I think they'll get the message. I think talking about contributions of low effort 'my-hello-world-lib' packages to repositories and contributions to existing codebases have a pretty different dynamic which we shouldn't conflate. For instance, while the npm-cli project is obviously hugely popular as a piece of software, the amount of PRs they get isn't exactly overwhelming, and they seem to accept a high proportion of the ones that do get opened against the project. Nevertheless, the JavaScript ecosystem is flourishing by all accounts so I'm not that convinced that their repositories being that polluted are as much of a hindrance as some would like to make out. It's just not that much of a problem because people can work with recommendations, popularity, word of mouth or whatever and decide what packages they're willing to accept based on their own organisation's policies rather than having some central authority dictate it to them. You can also argue that a separation of concerns should happen here: Lists of curated packages can exist outside of the repository itself. I also just don't think it's Cargo's job to put artificial barriers in place. It should be the package maintainer's job to decide what is an appropriate level of difficulty to contribute to them if that's how they see fit to triage contributions. If they want to make it some labyrinthine thing with external dependencies that have to be built by drawing a pentagram in your own time and blood and summoning the elder beast who instructs you as to where to find a binary blob that you have to link against that was lost in the early 1500s then more power to them? But it's not Cargo's job to decide where that line gets drawn.

johnisgood 8y ago

Easier to jump over, which means that people who otherwise wouldn't have been able to pass, now can easily jump over. It reduces quality, doesn't it? What I meant was that due to eliminated barriers, you may get lower quality. I emphasize may here. Just in case.

geofft 8y ago
Only if a) the bar(rier) is correlated with quality and b) there are no other quality gates elsewhere in the process.
- johnisgood 8y ago
  So does anyone know if in this exact situation it is, or it is not, or are we all just assuming that it's necessary a good thing and bash on anyone who dares to bring it up that it may not be the case? I said "arguably", and yes, while I did not provide an argument, I thought someone else could.
  - geofft 8y ago
    Arguably, Nick Cameron is an agent of the Knights Templar and Cargo is a secret plan towards world domination. You need to say why you think things are plausible. (In this exact situation I do know that there's a quality gate later in the process, and it would be very easy for you to determine that too with at most five minutes of research.)
    - johnisgood 8y ago
      I know what you are trying to say. Personally I would like to hear convincing reasons why lowering barriers to contribution is inherently a good thing, in all cases. I mentioned a few cases later on where it might not be favorable, to me, at least. And again: it was just a way to get the attention of people who might agree with it, to hear their side. Or to start/stimulate a discussion. I don't like to just believe things because it sounds good and because it has been repeatedly said to be good, without explaining why. The point was to question it, or come up with scenarios where it is not favorable. Do you agree that such scenarios exist where it is not a good thing, or not?
captainbland 8y ago
We have code reviews and stuff for this. It's also totally possible for somebody to spend hours setting something up and then develop really bad code - it might even be more likely in situations where time is a constraint. Having people jump through arbitrary hoops that have nothing to do with the matter at hand is not a good thing. This is especially the case with rust which isn't exactly the most beginner friendly language to begin with.
- johnisgood 8y ago
  Code reviews, yes. Not all projects can afford to go through millions of contributions because the barrier was lowered or eliminated. So in that case it is not necessary a good thing to accept lazy contributions.[1] And before someone misinterprets, sure, you can work endless hours on a contribution and then submit it easily. This is not the case I am talking about, and this is not what we have observed in the case of these package managers either. Or at least that's what I did when I took a look at npm. If it's not polluted because anyone can submit their garbage easily, then what is at fault, exactly? [1] We are still talking about a package manager, and this project specifically.
  - captainbland 8y ago
    I think that as a package maintainer, you can set the bar(rier) as high or as non-existent as you like. If you've got a lot of contributors, you've almost certainly got some regular contributors who you'd be able to trust to review/triage things for you. Otherwise just stick a big note saying 'we're full up, not accepting PRs, find another project, file or support a bug, the princess is in another castle' on your readme. I think they'll get the message. I think talking about contributions of low effort 'my-hello-world-lib' packages to repositories and contributions to existing codebases have a pretty different dynamic which we shouldn't conflate. For instance, while the npm-cli project is obviously hugely popular as a piece of software, the amount of PRs they get isn't exactly overwhelming, and they seem to accept a high proportion of the ones that do get opened against the project. Nevertheless, the JavaScript ecosystem is flourishing by all accounts so I'm not that convinced that their repositories being that polluted are as much of a hindrance as some would like to make out. It's just not that much of a problem because people can work with recommendations, popularity, word of mouth or whatever and decide what packages they're willing to accept based on their own organisation's policies rather than having some central authority dictate it to them. You can also argue that a separation of concerns should happen here: Lists of curated packages can exist outside of the repository itself. I also just don't think it's Cargo's job to put artificial barriers in place. It should be the package maintainer's job to decide what is an appropriate level of difficulty to contribute to them if that's how they see fit to triage contributions. If they want to make it some labyrinthine thing with external dependencies that have to be built by drawing a pentagram in your own time and blood and summoning the elder beast who instructs you as to where to find a binary blob that you have to link against that was lost in the early 1500s then more power to them? But it's not Cargo's job to decide where that line gets drawn.