Don't be that open-source user, don't be me

> It's best to conform to the contribution process described by the maintainer to avoid wasting their time as much as possible.

It’s not their prerogative to waste my time, just as it’s not mine to waste theirs. If they’re not happy with a PR they’re welcome to reject it, ask me to fix it, or completely ignore it.

When they make a project public they’re explicitly condoning the fact they may get a PR (and nothing else).

The company Grafana and the open source project Grafana have different customers with different requirements and requests.

If BigCorp wants purple widgets for their next massive migration towards Grafana and a bunch of free users are asking for the Foobars to be yellow then I don't see why it would make any sense for Grafana to take widget purplelization manpower away from their paying customer to yellowify foobars.

You've placed your upvote, your request has been noted and noticed. Next time there's dev capacity free there will be an evaluation of the most pressing open source issues and your concerns will probably be taken into account.

If you really need or want a feature, either build it yourself and send a PR or pay someone (probably the Grafana devs) to build it for you. Don't expect Grafana to solve your problems for you if you're not an important, paying customer, because they're a business; the focus should be on what keeps the lights on, not on which issue attracts the most vocal crowd on Github.

Maybe Grafana doesn't want what you want. Some features should not be in some products or implemented in some ways. Maybe something is of such little influence that you can be reasonably sure that only the free users will ever use a feature (i.e. features that compete with your paid offering).

I agree that entitlement is a two way street, but not in the way you probably think about it. If your users act entitled to support and attention, you're entitled to some kind of compensation.

that's not necessarily a recipe for success. As the (admittedly over-quoted) Ford quip goes."if I had asked them what they wanted, they'd have said faster horses".

Software development requires a solid amount of confidence to ,at times, be willing to disappoint users to keep a project on track. If you listen to what is likely an incredibly scattered and unfocused sea of requests you're going to lose control quickly. Torvalds and Linux are one positive example of someone who has maintained control often against demands.

I think asking for support is fine unless it is against the project guidelines.

I think reporting bugs is almost always great.

But I think that few if any projects and maintainers appreciate adding just "weight" in a comment. These comments just add load to whatever channel the maintainer uses to follow these things. If the comment has more valuable, like explaining a new use case that is affected by the issue then I think it has value. Otherwise just use the reactions feature.

Very much the same here. I'm the maintainer of Outline (https://github.com/outline/outline) – which uses Nodemailer by the way, thanks! – and folks still push through all of the GitHub workflows that try and direct self hosting support tickets to the discussions board and post them as bugs instead . This is much more annoying and time consuming than the +1 comments which can largely be left without a direct response.