There are a bunch of refinement tweaks that average users have made over the years that have never been committed to Gramps. They have stalled permanently.
These are minor things like: typos corrections, Tooltip harmonizations, defaults, icons, or color selections. These are trivial in terms of code but makes Gramps a bit more polished.
The user has already searched the source files and made the tweak on their own installation. But they don’t ever expect to do enough code for them to battle through learning GitHub. It isn’t terribly complex to get an MantisBT account… so they might even go as far as to submit a Feature Request.
But this is where the tweak stalls because other things demand the limited free-time of established developers.
This is generally because the changes are too trivial for a Developer to review or process in GitHub.
Maybe some of the new volunteers (who are not yet comfortable enough with the Gramps core to develop significant code) could be tasked with moving the minor tweaks from Mantis, the Discourse forum, or the Maillist archives to Pull Requests?
This would make them comfortable with the GitHub tools and ease their path to contributing their own code.
That’s a possible approach. But we are talking about a new ‘status’ that the volunteers doing triage would use. Not a new ‘tag’, right? (As a tag, a developer-oriented “good first assignment” would be better “1st issue” that sound ‘submitter-oriented’)
Mantis supports the following status options by default - New, Feedback, Acknowledged, Confirmed, Assigned, Resolved, and Closed
Unfortunately, I haven’t spotted an option to “Assign” to a queue of MantisBT … so that it works like an ACD system in a Tech Support call center.
Thanks for your comment. I’m with you that creating a new ‘status’ may be too complicated, and frankly doesn’t seem to fit, i.e. an issue doesn’t go in and out of a Good First Issue status. BTW, I suggested Good First Issue because it’s fairly common in GitHub.
A Good First Issue tag in Mantis (and label in GitHub) is simply an indication of someone’s evaluation of the issue without any other implications. It should not add a requirement that the triager evaluate for being simple to fix. However, if an issue is identifiable as such, add the tag as in the issues you identified - typo fixes, simple logic fixes, text updates, etc.
When a new dev wants to help, we simply point them to a summary report or Mantis filter and recommend they start their search there, which may encourage them to set up a repo, make the changes, submit a PR etc.
We’d have to be certain to regularly curate the issues associated with such a tag.
The tagged Issues that weren’t “Confirmed” status would need to have that Tag cleared aggressively. Otherwise, it would become too littered with Assigned & Completed issues. The tag probably needs to be limited to a quantity of issues that wouldn’t overwhelm newbie contributors with options.
You’re right, we would need a filter that shows only issues that aren’t closed/resolved. That’s quite easy to set up, and with a permanent link to that filter, it could be shared on the wiki, and even added added as another view on the Summary page on Gramps Mantis. Other than that, this tag wouldn’t be different from any other tag in Mantis, so we could see how it works for a while to see if anything more needs to be done.
Actually I just noticed a Good_First_Issue tag in Mantis - awesome! For consistency with existing tags, replacing the underscores with spaces or just removing them would be better, i.e. Good First Issue or GoodFirstIssue.