4 ms·
> or if you open issues I feel like there should be an exception carved out to this policy, if the submitter of an issue is offering to create (or, as a corpor
by derefr 1y ago
> or if you open issues
I feel like there should be an exception carved out to this policy, if the submitter of an issue is offering to create (or, as a corporation, dedicate their own engineers' time to creating) a PR to resolve the problem the issue describes.
As a maintainer of a few OSS projects myself, I see my fair share of "choosing beggars" (i.e. people who don't mentally model others' motivations, and so use github issues to essentially say "I got this for free, but it's not perfect for me, so can you please improve it in ways X/Y/Z to better suit my needs?" — without any consideration of whether their suggested improvement would ever benefit anyone else.)
But if an issue's submitter offers to create a PR, then this makes it very clear that they're not operating in this mindset; and in fact, they're being quite considerate! By describing a real problem, and then offering to create a solution to that problem, they:
1. make sure that we actually want to solve this problem (i.e. that we don't think of their problem as a WONTFIX / something that doesn't belong upstream)
2. give us the opportunity to take over solving the problem ourselves, if we think it's some kind of highly-critical and finicky work
3. give us the opportunity to participate in / constrain / steer the design of a solution, before it gets developed (rather than just having code dropped in our laps and having to fight it into an entirely different shape)
And it often doesn't even matter if the developer in question really has the skill and experience to develop the proposed solution entirely on their own. To me, a dev who creates a half-baked PR that we can then help shepherd over the line over the course of weeks/months of back-and-forth with them in the PR thread, is someone clearly in the process of developing that skill and experience, and potentially becoming an active contributor to the project — or maybe even a future maintainer. This sort of willingness to engage in a non-drive-by way is incredibly valuable.
- thayne 1y agoIt's complicated. Reviewing a PR takes time and effort, and the maintainer may not want to do that for a feature that mainly benefits a company that isn't paying the maintenance fee. OTOH, as a maintainer, if a company finds a bug that would impact a lot of users, I would want them to report it, regardless of their payment status. But saying something like "Issues from paying customers/donors have higher priority" is kind of vague, and doesn't provide any concrete value to the payer. So I'm not really sure what a good balance would be.
- monocularvision 1y agoI guess the point is if someone discovers a bug and opens a PR to fix it, then that person is, in a way, also a maintainer. They are “paying” for the maintanence of the project in time and effort.
- robmensching 1y agoNo. A maintainer is someone who maintains the project. Fixing a bug is a great contribution and makes you a contributor to the project. But you need stick around the project for a while, fixing issues that keep the project running and doing tasks that aren't necessarily required for your use of the project to become a maintainer.
- jononor 1y agoI would only say that they have become maintainers if they consistently do so, over time. Including helping out in areas which is not directly useful to them. And thinking about the whole picture, not just individual features and bugs. And also putting in the time when it is needed, even though other obligations are pulling at them. Of course it is somewhat of a continiuum. And it always starts with being a contributor. So that is on the right path.
- robmensching 1y ago100%. We're still learning here. I also don't expect every project to choose the same policy on how they tackle issues/PRs when requiring an Open Source Maintenance Fee.
- elsjaako 1y agoI think this is one of those issues that only exists in theory, not in practice. If a company reports a bug in a clear and helpful way, it's probably going to get looked at anyway. Also, if a company cares enough about Wix to bother finding and documenting a bug, they should be willing to pay $60 for the software. So this is only a problem in the case where a company finds a bug, decides to report it, refuses to pay a minimal fee, and the maintainers are strict enough with themselves to ignore it because of the source. That feels unlikely to me.
- robmensching 1y agoWe're still working through the best way to talk about issues and PRs. This is an area where I expect maintainers to differ in how they apply the OSMF (every maintainer I've spoken to is 100% behind requiring payment for binaries). I wholly agree with the sentiment of your comment and we're still learning. Note: At this time, my project (WiX Toolset) does not require the OSMF for PRs. If there is a README that says we do, then I probably need to fix it.
- entuno 1y agoAnd also an exception for reporting security-related issues. Because if you try and charge people money to responsibly report security vulnerabilities, then they'll just end up taking the full disclosure approach, which is probably not what you want.
- robmensching 1y agoOh, definitely. CVEs have a special place to be reported in GitHub. PSA: Do NOT use the issue tracker to report a CVE. That makes everyone's life difficult. Go through the correct channel.