TropicalPenguin commented on issue #343: URL: https://github.com/apache/age/issues/343#issuecomment-1344991954
I think what is at issue here is mostly not bounties, even if they may add some interesting wrinkles. But rather gatekeeping standards. People will of course differ on what kind of constraints these standards would enforce. Personally, I'd see their primary role as promoting and preserving the interests of users. And this standard seems to dissolve a lot of the messiness in the concerns you mentioned, and the questions you highlighted. Firstly, it renders this a very odd standard for an open source project: > @TropicalPenguin Please hold back on submitting bounties for features that aren't implemented yet, or appear to be missed or overlooked. This is an area that PMCs and committers need to address and rectify, using the proper channels and proper procedures - many that you are not a party to. There are a lot of internal discussions, design decisions, and roadmaps that go into a feature - they take time. Plus, we don't want to have a duplication of work and the messiness that may cause. We don't want the bounties to start causing issues or too much noise so, let's try to find a happy medium. Do feel free to ask if something falls into this category. Which one can see simply by replacing the word 'bounties' in the above with 'patches' or 'pull requests'. Given that the goal of the former is to stimulate the latter, the precedent would be identical. I think you at least implicitly realised this when the language was toned down in later remarks: > I don't mean to discourage anyone from contributing to the project, quite the opposite. But, I do feel that everyone should try to coordinate their efforts. I think open source ecosystems offer richer potential for coordination than what people might generally see in more corporate settings. In this kind of environment, I don't see independent streams of work as violating coordination at all. The byproducts of each stream can reveal each-others' mutual blindspots; code and ideas can be shared between them, which can further inform future developments. Done well, I think gatekeeping can serve this. So, as a general point on bounties before some thoughts on the questions you've highlighted... I think the _only_ obligation created by a bounty is for those offering the incentive, to deliver the reward to those who are the first to provide a solution they alone are happy with to a given issue. _Anything_ more than that is extraneous to the bounty itself. > Do we approve a bounty over another submission, or not, provided they are equivalent? And both are submitted reasonably close. I think this is conflating bounties with work product. Approval of bounties falls *only* to bounty providers. The gatekeeping of work product making its way into a given repo can proceed as it would even without bounties. In the (probably not too common, in practice) situations where there are multiple submissions, or anticipated submissions, the gatekeepers can decide which they prefer (if any), or can decide on parts of each to combine. > What happens if the bounty submission isn't approved, but the fix was valid? Mostly upside, I'd expect. Though the extent of upside will be modulated by whether the submission was rejected for good reasons. Even if something isn't approved in one form, it's still capable of providing the desired solution to whoever opened the bounty, assuming they're capable of integrating it into their own deployment. If it was rejected for good reasons, there would likely be an even better solution later, in the mainline repo, which anyone using the placeholder solution can then migrate to, if they wish (with the current case this is simple, since it's with regard to query syntax, as opposed to lower-level data structures, for which changes are more consequential). Having a given solution in the central repo mostly just makes things more convenient. > How much support do we give to someone working on a bounty? This is one of the more interesting questions here. I think it'll be subjective, not only to the person asking it of themselves, but also according to what the bounty is for and who is working on it, and even depending on what support is being called for. It'll be easy to imagine someone working on the same problem having different incentives to someone working on other problems. At which point I personally would hope to go back to the ideal of 'promoting and preserving the interests of users'. And there may be some situations where acting by such a principle would mean *not* supporting. Very contextual though. > What if the feature/fix requires design and implementation decisions to be made? I'm fond of the mantra "release early, release often", because it avoids the pretense that everything needs to be anticipated before work can begin, and instead allows the work itself to reveal answers to questions that were difficult to foresee. Which goes back to my earlier comments on coordination > What if one of the Apache AGE PMCs were to complete a bounty? > Should that bounty be given to whomever fixes the issue the bounty is tied too? I think the only difficulty here arises when a team of people is credited for a solution. But if they coordinated in the first place to achieve that, I expect they can negotiate how to apportion credit amongst themselves. But I think this up to the team, not those providing the bounty itself. > Should we even work on an feature/fix/issue that has a bounty on it? Similarly subjective to the question of support. I guess a primary variable of interest becomes: how discerning is the bounty provider of the quality of a given solution? (and "can I provide feedback to assist this discernment?"); that is, if I expect my work to be of a higher standard, but someone else is going to cut corners (assuming the bounty provider will accept it) just to get the bounty, why would I bother? I imagine attitudes would be different depending on the issue in question, and personal sense of those funding the bounty. Personally, I think that as long as a project has good gatekeeping, this dynamic has way more upside than downside. It circumvents "making the perfect the enemy of the good". And good solutions in the short term can facilitate better solutions in the medium-to-long term. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
