Tiny contributions

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.

Related to: Can Non-programmers contribute to 5.2?:

As an example:

Feature Request 10546 : Update obsolete terms in tips.xml

Completing this feature request to update the built-in Tip of the Day only needs:

  • a PR to be submitted for the (updated and attached) tips.xml file.
  • adding a MantisBT note to the Feature Request (identifying the PR and the branch …5.2 or 5.1 maintenance… where the PR will be committed so that the MantisBT item can be closed.)

Established developers are not going to be interested in the “Tip of the Day”. They will have outgrown it so long ago that they may not even remember that it exists.

The “Ancestry view” became a “Charts view” between version 3.3 and 4.0 of Gramps — a decade ago. But there were still 2 Tip of the Day listings for them.

It is wasteful to task a senior programmer with coding this kind of text tweak and posting the PR.

What do you think about adding “Good First Issue” as a tag to Mantis? If an issue can be assessed as an easy one to fix, tag can be added, making it easy to locate them later.

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’)

Admin Guide
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.

And this 2005 MantisBT feature request leads a person to think that they’re not going that way.

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.

Here’s an example of how Microsoft uses it: FSharp repo - list of good first issues.

2 Likes

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.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.