16 ms·
Yes, for just this reason I am beginning to remove my projects from Github. I have "given back" by posting my Haskell libraries to Hackage, where they may be u
by massysett 6y ago
Yes, for just this reason I am beginning to remove my projects from Github. I have "given back" by posting my Haskell libraries to Hackage, where they may be used and inspected by all. I'm not going to "give back" by maintaining software to the specifications of others, free of charge.
This level of "giving back" is not trivial: I have often benefitted from seeing the source code of other projects and deciding I don't want to use the library, or seeing the code and deciding to modify it or take a different approach - or seeing the library and realizing that I wanted to try something similar, but this library shows me why I shouldn't do it. Maybe others will similarly benefit from seeing my stuff. If they see my stuff and think it's deficient, wonderful! Alter it to make it fit your needs, or use it as an inspiration for your own fresh rewrite.
But I'm not maintaining software for other people. God bless people who do; that's wonderful. But it's perfectly OK to just post stuff up in case someone else wants to use it. When people see the code on Github they think "oh I can make feature requests" or "I can send a PR." Fair enough - Github is "social coding" after all. So I just won't put code on Github.
- cies 6y agoThis 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 agoThe 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 agoAsking 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 agoThe 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 agorightfully -> understandibly
- mitjak 6y agoi 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 agoI 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.
- enriquto 6y agoThe 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.
- vzaliva 6y agoWhat if somebody sends you an email patch?