What do people think about adding a “Feature Requests” category?
The idea would be that users could vote for features that they would like to see in Gramps. This would give us an indication of the popularity of a feature request.
There would be no guarantee that the most popular features would be implemented. All our developers are volunteers and they work on features that interest them.
I don’t want to duplicate the bug tracker, so if a feature request already exists we could just add a brief description on this forum together with a link.
Unfortunately we don’t have access to the Discourse Topic Voting plugin on our free plan. Would using the thumbs up and thumbs down would be sufficient?
If enough people are enthusiastic we could give this a trial.
Good idea to give it a try, but is “performance improvement” a feature?
Or do you need to be more specific like “improve loading of source/citation window”?
Is this forum truly representative of the full number of users which
I suspect might be an unknown and probably not.
If there is no developer willing to work on a feature request then
they are not going to happen anyway.
phil
To all developers thanks and keep up the good work
I’m looking for a way for users to indicate which bug report or feature request is most important to them. So perhaps “Feature Requests” is the wrong name. I would also like something to have progressed to be more of a solid proposal rather than just an idea.
Something specific that a developer can work on would be best. Smaller changes would stand a better chance of attracting a developer.
Broader questions like “Do you think that performance of Gramps needs improving?” or “Should we aim for full Gedcom 7.0 support?” would be interesting. Maybe an opinion poll would be better for these? We have conducted polls in the past.
Understood, sorry I’m not sure what to call it then, but feel that it is overcomplicating things, personally I suggest repurposing the Idea’s category.
That Gauge Support plug-in for MantisBT looks like a more actionable polling system.
The wishlist is a moving target and the MantisBT addon can support that.
The Polls here on Discourse are too static. They don’t allow adding new items once the 1st vote has been cast.
It supports current process: The GitHub commit, RoadMap and Release Notes need a MantisBT issue to map against.
And we could make a “Wishlist” Discourse posting into a wiki. New wishlist items could be added or removed as needed.
The wishlist it has links to the MantisBT issues for voting and a Discourse thread for discussion. The way Discourse shows a count of “link followed” would give a rough gauge of interest. This helps gauge interest of users who don’t have a MantisBT account.
The Discourse markup (like Ins, Del, and Mark) could be used to indicate “new”, “completed” and “critically needing feedback” respectively. The "completed"s from the posting could be the foundation of a linked Release Note that help accelerate documenting new feature in the wiki. And the Posting (with the "completed"s trimmed out) could be the seed for the next version wishlist.
@Nick-Hall The Gauge Support Mantis addon you found seems to satisfy both the goals you stated in your original message, so that is definitely worth a trial.
I see value in using the Discourse forum to gather input and feedback from the community before and during development on feature requests chosen for development. Case in point is the forms project this summer - great use of the forum and an example of how to involve users directly.
My concern with using the forum to log new ideas in addition to MantisBT is that it would create two ways to solicit ideas, and increase the likelihood that we will spread information over both platforms and confuse our users. [edit: This wasn’t being proposed, feel free to ignore this para]
Let’s say we use the MantisBT addon. With 1,478 open feature requests (including many potential duplicates) the question is which subset of those would help create a release of great value to the Gramps user community? By creating a theme for the next major release, we could sift through the feature requests in MantisBT and focus on issues related to that theme and then bring those to the forum.
BTW, how do GEPs fit into the picture? Are they still used?
We may not want to use AIs in development. But it might worthwhile to contract one for about 3 to 6 months to train on our MantisBT dataset to become a SME.
1,500 issues is too much for a human to rationalize the dataset in a reasonable amount of time. That would be a thankless and tedious task. But an AI could lock down the duplicates and flag the proposals in Notes that haven’t been raised to a PR.
Probably not, but Mantis bug tracker is defintly not that either. I think the only way to truly reach a representative gramp userbase group, would be to include it in Gramps. And this doesnt fit there.
As long as it always require the actions of an actual person before things get locked, linked, etc. I think having AI automatically lock stuff without human input would be an bad idea.
[quote=“emyoulation, post:11, topic:5867”]
1,500 issues is too much for a human to rationalize the dataset in a
reasonable amount of time. That would be a thankless and tedious task.
But an AI could lock down the duplicates and flag the proposals in Notes
that haven’t been raised to a PR.
[/quote]
I would take the simple route first pass, anything older than 6 months
is probably never going to happen so bin it.
Or take the latest feature request number minus 100 and bin everything
with a lower number
Phil
That is the kind of “collating” grunt work that is ideal for AIs.
However, as you pointed out, AIs should generate reports and build ‘recommended change lists’ that a human would have to accept rather than do things autonomously. They simply hallucinate far too often to be set free in any project.