When Benthos hands you lemons this page lists people to angrily throw them at.(That was just a metaphor - lemons not provided)
Benthos has a helpful and conveniently global community so if you have quick questions, are in the market for ideas, or just want to make some friends, it's worth trying your luck with our community spaces. However, for organisations that want quicker action, guaranteed attention or some one-on-one consulting time there are some paid services available that are worth considering.
Paid services options range from ad hoc appointments to long term contracts. These can be tailored to your particular needs and are subject to availability, so please reach out to email@example.com to get started. The following is a broad list of services offered, it'd speed things up to have one of these in mind when you contact us:
If you'd like a specific feature or bug to be addressed within a specified time period then an issue bounty can be set whereby an agreed amount will be paid upon completion of the issue. This is often a nice way of paying for specific features to be built when a longer term contract isn't necessary.
In order to set a bounty please reach out with a description of the issue (or a link to it on Github) and a desired time frame and we'll provide the value of the bounty, it is then up to you whether you wish to proceed.
If you feel it's likely that you might require one or more of the above services regularly then you can retain a certain number of days of support each month. This would allow you to get quicker access to services with an agreed upon response time.
It's worth noting that the support offered at certain Jeffail Github sponsorship tiers might suffice for some smaller organisations.
Nothing makes the Benthos community happier than welcoming new blobs into our blobosphere, and that includes answering questions, helping you to fit Benthos around your use cases, and general chit chat about the project, and there are multiple spaces where you can find us. However, we are a finite number of entities (for now) and there are limits to how much of our free time and energy we can realistically spend on these activities.
Keeping the community cogs turning is therefore a balancing act between encouraging shy users to seek help when they need it, and gently teaching others (the noisy ones) how to reduce their reliance on our help. Here's some tips on how to get the best of us.
Before Asking for Help
Try the Documentation
Give the Benthos documentation a try, no one expects you to read the whole thing but it's there for a reason. Try using the search functionality and if there's a section that covers the area you're looking at then try your best to understand it. However, with that said, you will not be judged for missing something, if you're not seeing the answers you need then asking the community is definitely the reasonable thing to do.
Consider a Simpler Approach
When you have a particular solution in mind it's easy to slip into a mindset that blocks you from considering other approaches even when it's not working out. If you're struggling to find out how to make your solution work with Benthos then take a deep breath, think about ponies or something for a few minutes, and consider if there's a more Benthosy way in which your problem could be solved.
If not then we still want to hear from you as maybe it's an interesting use case we can implement a proper solution for, but it's good to have considered other approaches before it gets to us.
Test Things Yourself
Benthos has lots of ways to try solutions out, it has unit tests, a
generate input, a
benthos blobl server subcommand, and many more ways to get some trial and error done before asking for help. It's frustrating for us to spend our time reading and understanding configuration files and use cases that make up part of your question when it could have been answered with a few seconds of testing.
When Asking for Help
Focus on the Problem
When asking us for help try and focus on the specific problem you have rather than the higher level details. Ideally we want to see things like concise examples of data you have versus what you want to get out, or a description of how you want data to flow through your pipeline. Please also reduce config examples down into the basics that are relevant to your question. Any details that you provide that isn't specifically part of the problem is only a hurdle that we will need to overcome before we can understand your question.
If your particular question requires knowledge of private and commercial applications that you have built or are building then the public support channels are not the right place to ask it.
Reproduce Your Issue
It's common for users to point out an issue they're seemingly having with Benthos and it then turns out to be an unrelated issue with cached builds, configs not being saved, docker images not being pulled fresh, etc. These encounters may sound rare but anecdotally they occur more often in our support channels than actual bugs, and we've spent considerable measures of time trying to reproduce issues that don't exist (yet). By attempting to isolate and reproduce issues yourself you can significantly reduce the burden on us.
Things that a typical community member cannot do include mind-reading, assuming control of your PC (I hope) and time travelling into the past in order to obtain context of the problem on your behalf. In order to work around these limitations please make sure that when you are asking us for help regarding a problem you've had that at the very least you are able to give us any error messages/logs that were emitted by Benthos when it happened.
Never Direct Message
Unless you are explicitly instructed to do so please never direct message maintainers or community members for support, and avoid directly pinging them. If you aren't receiving responses in a public support channel it is because they currently do not have time to address your issue, please be patient or consider a paid support option instead. Direct messages only serve to add extra pressure on volunteers, and answering questions via direct messages denies other users the opportunity to read the answers for themselves.
If there is sensitive information within your question that you do not want to expose publicly then please take the time to scrub that information from the material you are sharing.