* file a PR with a description of the problem, how to reproduce it,
and include a patch;
* then poke the maintainer directly if you know who it is;
* then keep gently poking them if they forget.
Having a good description of a problem, including how to reproduce it,
makes it quite a bit more useful to me as a software archeologist when
I want to try and understand the why behind a fix. The what may be
easy to figure out, but not the original reason. Doubly so when I
decide to take over a subsystem and would like to understand some of
the history/evolution of the codebase.