4 ms·

This is important. We need some vocabulary definitions for all different levels/aspects of "open". Open Access, or not. Open for contribution... or not. Comm

by cies 6y ago

This is important. We need some vocabulary definitions for all different levels/aspects of "open". Open Access, or not. Open for contribution... or not. Commit ownership transferals, or not. In some cases there are whole steering committees.

mumblemumble 6y ago
The vocabulary is already there. What is out of place is the perception of where the defaults lie. Right now we seem to assume that, unless someone takes the time to write out rules explicitly saying what they're not willing to do, then they must be willing to do it. It should be just the other way around. If a project wants contributions, for example, then they can communicate that by posting contribution guidelines in the README.
- peteretep 6y ago
  > It should be just the other way around It should not be just the other way around
- kenniskrag 6y ago
  Asking the maintainer if you are allowed to provide a fix is an option? Open pull requests are better than no pull requests. If the maintainers don't want them merged to their code base, other users can still merge them to their base.
  - deleted 6y ago
    [deleted]
  - imtringued 6y ago
    The real problem is that pull requests are the wrong form of communication. By the time someone sends a pull request they already put a significant amount of effort into their message and thus will rightfully get angry when their efforts are being rejected. You need to contact the maintainers directly and talk with them, preferably in an informal format where it is okay for things to be forgotten or thrown out. The fact that things are written down and recorded forever with an expectation of work is what is causing all the problems.
    - cies 6y ago
      rightfully -> understandibly
    - mitjak 6y ago
      i dont think anyone submitting an unsolicited PR should be expecting it to be merged in. it's a way to convey a complete idea, not a guarantee of merging.
      - anticristi 6y ago
        I do that. I sometimes prefer PRs to discuss my improvements. By the time I answer questions such as "how intrusive would this change be", "what exactly needs to be changed", "how would I test my change", I'm already halfway through the PR. I agree that sending a PR should not be considered a guarantee of merging. Rather an issue that is discussed with a mixture of prose and code.
      - kelnos 6y ago
        No, they shouldn't be expecting anything, but a lot of people will. And that's just how it is. If we don't want people to waste their time and potentially get upset, we should write out up-front what our contribution policy is. Note that I'm not talking about how the world should be. I'm talking about how it is. I agree that people shouldn't just write up a PR without any prior communication with the maintainer and then expect it to get merged. But people do; that's just reality.
        mitjak 6y ago
        absolutely. im on the side of documenting and reiterating to get this across.
    - phkahler 6y ago
      >> By the time someone sends a pull request they already put a significant amount of effort into their message and thus will rightfully get angry when their efforts are being rejected. I'd prefer if they open an issue - or use an existing one - as a forum to discuss what they'll be doing in a PR. That way we can either reject an idea prior to someone putting in the effort, or talk about implementation so the resulting PR is more likely to be accepted. Drive by PRs are fine if they're simple, but the ones of higher impact need more consideration. Even more than PRs, I have mixed feelings about feature requests. Many of them are legit things that would make the software better, but with limited resources they're likely to sit for years. Is it better to let them pile up or close them? Maybe a new tag - Deferred.
  - yawaramin 6y ago
    > Asking the maintainer if you are allowed to provide a fix is an option? It is (or should be) a standard practice to file an issue on the repo and ask there before starting work.
    - vorpalhex 6y ago
      Even if the repo is open to PRs, you want to make sure you're not duplicating work someone else is doing and that you have all the requirements.
enriquto 6y ago
The vocabulary already exists. For example, the lua project clearly states lua is free software but it is not open development, all development happens behind closed doors.

by cies 6y ago

mumblemumble 6y ago

The vocabulary is already there. What is out of place is the perception of where the defaults lie. Right now we seem to assume that, unless someone takes the time to write out rules explicitly saying what they're not willing to do, then they must be willing to do it. It should be just the other way around. If a project wants contributions, for example, then they can communicate that by posting contribution guidelines in the README.

peteretep 6y ago
> It should be just the other way around It should not be just the other way around
kenniskrag 6y ago
Asking the maintainer if you are allowed to provide a fix is an option? Open pull requests are better than no pull requests. If the maintainers don't want them merged to their code base, other users can still merge them to their base.
- deleted 6y ago
  [deleted]
- imtringued 6y ago
  The real problem is that pull requests are the wrong form of communication. By the time someone sends a pull request they already put a significant amount of effort into their message and thus will rightfully get angry when their efforts are being rejected. You need to contact the maintainers directly and talk with them, preferably in an informal format where it is okay for things to be forgotten or thrown out. The fact that things are written down and recorded forever with an expectation of work is what is causing all the problems.
  - cies 6y ago
    rightfully -> understandibly
  - mitjak 6y ago
    i dont think anyone submitting an unsolicited PR should be expecting it to be merged in. it's a way to convey a complete idea, not a guarantee of merging.
    - anticristi 6y ago
      I do that. I sometimes prefer PRs to discuss my improvements. By the time I answer questions such as "how intrusive would this change be", "what exactly needs to be changed", "how would I test my change", I'm already halfway through the PR. I agree that sending a PR should not be considered a guarantee of merging. Rather an issue that is discussed with a mixture of prose and code.
    - kelnos 6y ago
      No, they shouldn't be expecting anything, but a lot of people will. And that's just how it is. If we don't want people to waste their time and potentially get upset, we should write out up-front what our contribution policy is. Note that I'm not talking about how the world should be. I'm talking about how it is. I agree that people shouldn't just write up a PR without any prior communication with the maintainer and then expect it to get merged. But people do; that's just reality.
      - mitjak 6y ago
        absolutely. im on the side of documenting and reiterating to get this across.
  - phkahler 6y ago
    >> By the time someone sends a pull request they already put a significant amount of effort into their message and thus will rightfully get angry when their efforts are being rejected. I'd prefer if they open an issue - or use an existing one - as a forum to discuss what they'll be doing in a PR. That way we can either reject an idea prior to someone putting in the effort, or talk about implementation so the resulting PR is more likely to be accepted. Drive by PRs are fine if they're simple, but the ones of higher impact need more consideration. Even more than PRs, I have mixed feelings about feature requests. Many of them are legit things that would make the software better, but with limited resources they're likely to sit for years. Is it better to let them pile up or close them? Maybe a new tag - Deferred.
- yawaramin 6y ago
  > Asking the maintainer if you are allowed to provide a fix is an option? It is (or should be) a standard practice to file an issue on the repo and ask there before starting work.
  - vorpalhex 6y ago
    Even if the repo is open to PRs, you want to make sure you're not duplicating work someone else is doing and that you have all the requirements.

enriquto 6y ago

The vocabulary already exists. For example, the lua project clearly states lua is free software but it is not open development, all development happens behind closed doors.