I don't speak for gramps. (I just occasionally volunteer to
help.) So the following are only my personal opinions.
Besides what others have said, I would add that in the year
since 5315 was filed over eight hundred bugs, features, etc.
have been added to the gramps bug tracker.
Since the gramps development community is not large, and is
quite varied as to their interests and time available, the
odds start off being very small that some developer will (by
chance, nothing is automatic,) notice some particular bug.
But each one already has somebody who cares about it (since
otherwise the person who reported the bug or asked for the
feature would not have taken the time and effort to do so).
So one way they can increase the chances theirs will be paid
attention is to give as many details as possible. There is
a "Steps To Reproduce" section. Fill it in, if it's a bug.
Perhaps attach a screen shot (if you know how), or a family
tree which triggers it. Or test out your problem with a
family tree which ships with gramps, such as data.gramps or
example.gramps, in the example/gramps subdirectory, which
is even better. Every gramps comes with them both. (Many
problems are specific to the user's data, which users often
do not realize, when they file a bug report.)
As has been said, for a feature request, talk about what
you want or what you don't like. Be specific. Realize
that the developer reading your request or complaint may
not be as familiar with the circumstances as you are.
In my case, for instance, I've never run the narrative web
report "for real" in my life (and have no plans to). The
few times I've tested something with it I was only paying
attention to some specific narrow part of it. Perhaps if
I saw a bug which was documented thoroughly I might have
been willing to look into it. Perhaps not. Perhaps if I
saw a feature request which seemed clear to me I might be
willing to see if I could reproduce the problem, and then
see if I could understand things enough to add the feature
the user wanted. Perhaps not. But I will certainly be more
likely to read the next bug report or feature request if I
don't think I understand what the user is saying or asking.
Similarly, have a subject line which makes somebody want to
read it. If it's too vague or too general it might not even
be read at all, or only by far fewer people.
As has also been said, any user might want to consider if
they want to look into it themself. We have developers who
started out as users of gramps and then started altering or
fixing things (me for instance, and probably others too). I
don't think it is impossible to learn. It just takes some
time, some interest, a willingness to want to help, improve
things. The gramps-devel mailing list has people who will
try to help you, answer questions, that sort of thing.
Another way which a user can help is by editing the wiki.
Anybody can do that (I believe signing up is automatic). Do
you think the knowledge in this discussion is widely known?
Probably not, would be my guess. Maybe somebody (anybody)
wants to add it to the wiki? Documentation is good. If you
can help improve it you would make the gramps experience a
little better, for everybody. Write a wiki page, or edit an
At any rate, thank you for your interest in gramps.