The "example" I had in my head when writing that one where I found a pretty nasty bug in a relatively small library I was using.
I opened an issue, but struggled on how to get across the feeling of "If this isn't fixed i'll need to do it myself", but without the demanding feel.
I'm completely okay with a "can't get to it now" and i'll take over and fix the problem in the library myself for myself (making a PR if it makes sense to), or completely replace it with my own code or another library. And I would never fault the maintainer for not having time, or just flat out not wanting to fix it for me.
But having written that out, I see what you are trying to say. There's no need to point out my timelines, or ask for an ETA or anything like that. At the end of the day I'm responsable for my code, so I'd be better off just making the issue about the actual issue, and set a deadline (internally in my team or to myself, not publicly) that if it's not fixed by that time I do it myself.
In your example the answer seems clear to me, communicate that you have a deadline, but are willing to fix this if they are busy and ask them if they have any thoughts on how they would like the issue to be resolved.
Exactly. I am very comfortable saying "please send a pull request" in response to the request for a feature, or the report of a bug. I try to be overtly encouraging, suggesting that when people suggest ideas, they dive in and try to build it.
The best way to scale a project and community is not to try to do everything yourself, and instead encourage other people and empower them to act. They may need assistance in the beginning, but the benefit will pay off in the long term: "If you give a man a fish, you feed him for a day. If you teach a man to fish, you feed him for a lifetime" (attribution unknown)
This does require giving up some control. Properly empowering people to contribute means that you need to, to varying gradual extents, respect their judgment and not try to veto or assert too much control. No person will work on any one project forever, and so a gradual and seamless transition of project leadership from one person to another requires a gradual trust in the other's judgment; trust in judgment necessitates room to make mistakes.
If you need something from a project or organization that you are not paying, then do not engage with the expectation that they'll do work for you. Instead, engage as a collaborator by offering to bring something to the table. Point out the bug, offer to fix it, and suggest a possible solution. Or if you just want to point out the bug, that's fine, but don't carry an expectation that someone will volunteer to fix it for you.
I opened an issue, but struggled on how to get across the feeling of "If this isn't fixed i'll need to do it myself", but without the demanding feel.
I'm completely okay with a "can't get to it now" and i'll take over and fix the problem in the library myself for myself (making a PR if it makes sense to), or completely replace it with my own code or another library. And I would never fault the maintainer for not having time, or just flat out not wanting to fix it for me.
But having written that out, I see what you are trying to say. There's no need to point out my timelines, or ask for an ETA or anything like that. At the end of the day I'm responsable for my code, so I'd be better off just making the issue about the actual issue, and set a deadline (internally in my team or to myself, not publicly) that if it's not fixed by that time I do it myself.