# Roadmap for v5.3 (correction: 6.0)

**URL:** <https://gramps.discourse.group/t/roadmap-for-v5-3-correction-6-0/5203>\
**Category:** Roadmap\
**Created:** [April 1, 2024, 6:18pm UTC](https://gramps.discourse.group/t/roadmap-for-v5-3-correction-6-0/5203 "2024-04-01T18:18:36Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![Nick-Hall](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/nick-hall/32/95_2.png) [@Nick-Hall](https://gramps.discourse.group/u/Nick-Hall)\
**Post date:** [April 1, 2024, 6:18pm UTC](https://gramps.discourse.group/t/roadmap-for-v5-3-correction-6-0/5203/1 "2024-04-01T18:18:36Z")

</div>

Now that the release of v5.2 is behind us, it is time to think about the roadmap for the next major release. I’ve already posted to the _gramps-devel_ mailing list, but user feedback is also important to us.

Firstly, I’d like to say that the time it took us to release v5.2 was far too long. At the start Covid was a factor, and then the amount of work required became large which was rather daunting. We must make an effort to release Gramps more frequently, and I have indicated that I am willing to trial a much shorter time between releases.

Next, and of more interest to users, is what new features do we want to see in v5.3?

I made a couple of lists contaning things that have already been mentioned to me. There are some big long-standing topics such as:

- Using JSON as the raw representation of objects.
- Allowing multi-user access.
- Improvements to the Gramps types.
- Modelling of ships and heirlooms - Perhaps creating a new “Thing” primary object?
- Place enhancements - will depend on other decisions made.

Some Gedcom related enhancements will probably be less controversial:

- Add creation date to primary objects.
- [Add identifier structure to primary objects](https://github.com/gramps-project/gramps/pull/1005).
- [Allow web-accessible files in media paths](https://github.com/gramps-project/gramps/pull/1447).
- Add dates to individual and family attributes.
- Add time and phrase to date objects.
- New Submitter primary object.
- Add translations to notes.

There are also ideas that I have probably forgotten. For example, the idea of sub-events seems to come up quite often in discussions.

I would like to hear what users would like to see in the next release, but please bear in mind that not everything can be implemented and we have to get developers interested in coding the new features.

If a feature is really popular though, it may influence our decisions and may even attract a developer.

---

<div class="post-metadata">

**Author:** ![comeng](https://avatars.discourse-cdn.com/v4/letter/c/2acd7d/32.png) [@comeng](https://gramps.discourse.group/u/comeng)\
**Post date:** [April 2, 2024, 6:57am UTC](https://gramps.discourse.group/t/roadmap-for-v5-3-correction-6-0/5203/2 "2024-04-02T06:57:28Z")

</div>

Nick

- Using JSON as the raw representation of objects. YES
- Allowing multi-user access. YES
- Improvements to the Gramps types. YES
- Modelling of ships and heirlooms - Perhaps creating a new “Thing” primary object? SO RARE NOT BOTHERED
- Place enhancements - will depend on other decisions made. YES

Some Gedcom related enhancements will probably be less controversial:  
IF THE DECISION IS TO KEEP GRAMPS INLINE WITH GEDCOM FINE BUT NONE OF THESE ARE IMPORTANT TO ME

- Add creation date to primary objects.
- Add identifier structure to primary objects.
- Allow web-accessible files in media paths.
- Add dates to individual and family attributes.
- Add time and phrase to date objects.
- New Submitter primary object.
- Add translations to notes.

My own would be  
Ability to Configure which columns are visible for each view individually  
Example I never want age displayed alongside events

Phil

---

<div class="post-metadata">

**Author:** ![StoltHD](https://avatars.discourse-cdn.com/v4/letter/s/db5fbb/32.png) [@StoltHD](https://gramps.discourse.group/u/StoltHD)\
**Post date:** [April 2, 2024, 1:17pm UTC](https://gramps.discourse.group/t/roadmap-for-v5-3-correction-6-0/5203/3 "2024-04-02T13:17:49Z")

</div>

Wish list in prioritized order:

1. Main-/Sub-Events
2. Events on Places, including first point.
3. Extend the Repository, Source and Citation functions in Gramps with support for using CSL and reading (as minimum, sync would be better) a Citation Store file like BibTex or CSL-JSON to be able to utilize an External Bibliography/Citation Manager.
4. A hierarchal system for Sources/Citations and Repositories with possibility to use Places as Repositories and visa verse.
5. Change the JSON export (and if possible, import) so that it is compatible with one (any) of the Open-Source Open-Data formats for linked data like JSON-LD or any Open-Source Advanced Network Graph format.
6. Using a multi-model database like ArangoDB, OrientDB or similar as backend in addition to SQLITE, Postgresql…

---

<div class="post-metadata">

**Author:** ![trlvn](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/trlvn/32/1148_2.png) [@trlvn](https://gramps.discourse.group/u/trlvn)\
**Post date:** [April 2, 2024, 1:28pm UTC](https://gramps.discourse.group/t/roadmap-for-v5-3-correction-6-0/5203/4 "2024-04-02T13:28:21Z")

</div>

> [@Nick-Hall](#):
>
> Allowing multi-user access.

Allow me to play Devil’s Advocate, if you will. I have some experience with a multi-user system (MythTV, a free, open source personal video recording system). In that case, and I suspect for Gramps, the vast majority of normal users don’t make use of the multi-user aspects. But it is significantly more complicated to install, troubleshoot and maintain.

In MythTV, there is a distinction between installing the “backend” and “frontend”. To simplify, the backend has essentially no user interface and handles recording videos and serving them to frontends. Users set up recording rules via the frontend and select recordings to watch, etc. MythTV uses either a MariaDB or Mysql database for television channel listing information and other data. In point of fact, the database can be run on a separate machine meaning a ‘basic’ installation could comprise three separate systems: database, backend and frontend.

In practise, typical users start with a single machine running the three components. A handful add another frontend or two so they can watch recordings on other televisions.

The “cost” is that a potential user–who just wants to record and watch TV–has to first get their head around some of this core complexity. There are easy install methods for single, combined systems but you can’t avoid the jargon completely. It is a non-trivial barrier for newbies.

I would hate to see Gramps become more complex for all users in order to satisfy a smallish group that really want multi-user access. I think it would be better to fork the project if some developers are really intent on multi-user. If they can provide a simple migration process, that’s wonderful.

My $0.02 (and Canada doesn’t even use pennies anymore).

Craig

---

<div class="post-metadata">

**Author:** ![Nick-Hall](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/nick-hall/32/95_2.png) [@Nick-Hall](https://gramps.discourse.group/u/Nick-Hall)\
**Post date:** [April 2, 2024, 1:37pm UTC](https://gramps.discourse.group/t/roadmap-for-v5-3-correction-6-0/5203/5 "2024-04-02T13:37:13Z")

</div>

> [@trlvn](#):
>
> I would hate to see Gramps become more complex for all users in order to satisfy a smallish group that really want multi-user access.

I agree. I am not even considering a client-server approach.

Multi-user access would be limited to making it safe for concurrent access to the SQLite database.

---

<div class="post-metadata">

**Author:** ![Nick-Hall](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/nick-hall/32/95_2.png) [@Nick-Hall](https://gramps.discourse.group/u/Nick-Hall)\
**Post date:** [April 2, 2024, 1:46pm UTC](https://gramps.discourse.group/t/roadmap-for-v5-3-correction-6-0/5203/6 "2024-04-02T13:46:07Z")

</div>

> [@StoltHD](#):
>
> Extend the Repository, Source and Citation functions in Gramps with support for using CSL and reading (as minimum, sync would be better) a Citation Store file like BibTex or CSL-JSON to be able to utilize an External Bibliography/Citation Manager.

You can probably do some of this already by writing a citation formatter (new in v5.2) and a custom importer.

> [@StoltHD](#):
>
> Using a multi-model database like ArangoDB, OrientDB or similar as backend in addition to SQLITE, Postgresql…

Again, you can do this using the existing addon mechanism. I may even be interested in experimenting with one of these databases myself when I have time.

---

<div class="post-metadata">

**Author:** ![Nick-Hall](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/nick-hall/32/95_2.png) [@Nick-Hall](https://gramps.discourse.group/u/Nick-Hall)\
**Post date:** [April 2, 2024, 1:58pm UTC](https://gramps.discourse.group/t/roadmap-for-v5-3-correction-6-0/5203/7 "2024-04-02T13:58:05Z")

</div>

> [@comeng](#):
>
> My own would be  
> Ability to Configure which columns are visible for each view individually  
> Example I never want age displayed alongside events

Such a request was anticipated when we introduced the resizable column widths in editor tabs feature. It would be possible to expand this functionality to also change the column sort order and visibility.

---

<div class="post-metadata">

**Author:** ![comeng](https://avatars.discourse-cdn.com/v4/letter/c/2acd7d/32.png) [@comeng](https://gramps.discourse.group/u/comeng)\
**Post date:** [April 2, 2024, 2:11pm UTC](https://gramps.discourse.group/t/roadmap-for-v5-3-correction-6-0/5203/8 "2024-04-02T14:11:26Z")

</div>

Concurrent Access is all I would wish not client/server  
Equivalent to Microsoft Access Relational Database functionality.

A hierarchical system for Sources/Citations and Repositories with  
possibility to use Places as Repositories and visa verse.  
I know this has been discussed and there are arguments both ways but was  
wondering whether it would be worth looking again not that I would give  
it a very high priority

Phil

---

<div class="post-metadata">

**Author:** ![comeng](https://avatars.discourse-cdn.com/v4/letter/c/2acd7d/32.png) [@comeng](https://gramps.discourse.group/u/comeng)\
**Post date:** [April 2, 2024, 2:14pm UTC](https://gramps.discourse.group/t/roadmap-for-v5-3-correction-6-0/5203/9 "2024-04-02T14:14:26Z")

</div>

Thanks for reply on that  
Phil

---

<div class="post-metadata">

**Author:** ![emyoulation](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/emyoulation/32/67_2.png) [@emyoulation](https://gramps.discourse.group/u/emyoulation)\
**Post date:** [April 2, 2024, 2:43pm UTC](https://gramps.discourse.group/t/roadmap-for-v5-3-correction-6-0/5203/10 "2024-04-02T14:43:12Z")

</div>

> [@Nick-Hall](#):
>
> Add creation date to primary objects

Can’t the [creation date be extracted from the Handle](https://gramps.discourse.group/t/reversing-an-object-handle-to-its-creation-date/2614)?

---

<div class="post-metadata">

**Author:** ![Nick-Hall](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/nick-hall/32/95_2.png) [@Nick-Hall](https://gramps.discourse.group/u/Nick-Hall)\
**Post date:** [April 2, 2024, 2:44pm UTC](https://gramps.discourse.group/t/roadmap-for-v5-3-correction-6-0/5203/11 "2024-04-02T14:44:50Z")

</div>

> [@comeng](#):
>
> A hierarchical system for Sources/Citations and Repositories with  
> possibility to use Places as Repositories and visa verse.  
> I know this has been discussed and there are arguments both ways but was  
> wondering whether it would be worth looking again not that I would give  
> it a very high priority

A hierarchical system for Sources/Citations could be interpreted in couple of aways:

- [Layered citations](https://evidenceexplained.com/content/quicklesson-19-layered-citations-work-layered-clothing)
- Source/citation organisation (e.g. catalogues, collections etc…)

The modelling of places and repositories is something that we have inherited from Gedcom. If an event happened at a repository then you would need a Place, and if sources are stored in a place then you would have to create a Repository. Does this actually cause a problem? How close to we want to stick to the Gedcom standard?

---

<div class="post-metadata">

**Author:** ![comeng](https://avatars.discourse-cdn.com/v4/letter/c/2acd7d/32.png) [@comeng](https://gramps.discourse.group/u/comeng)\
**Post date:** [April 2, 2024, 4:03pm UTC](https://gramps.discourse.group/t/roadmap-for-v5-3-correction-6-0/5203/12 "2024-04-02T16:03:51Z")

</div>

Hierarchical Sources

Can I explain my logic here as to why it is an interest to me

Years ago I was using the Registration Districts/sub Districts of the BMD system for location of Births, Marriages and Deaths

Originally they followed Ancient County boundaries which are physical Places of long standing.

So I then Created in each County a dummy Place called “Registration Districts of” and under each to the Registration Districts was a dummy called “Sub District of”. These were then classed as Administrative concepts because this type of place is loosely related to a Physical Place but constantly changing with the whim of local/national governance and therefore not given a physical location.

I do a similar thing with Probate Registries.  
So my places already have Sources and Citations associated with them via the Notes I create for individual events such as births.

Phil

---

<div class="post-metadata">

**Author:** ![comeng](https://avatars.discourse-cdn.com/v4/letter/c/2acd7d/32.png) [@comeng](https://gramps.discourse.group/u/comeng)\
**Post date:** [April 2, 2024, 4:45pm UTC](https://gramps.discourse.group/t/roadmap-for-v5-3-correction-6-0/5203/13 "2024-04-02T16:45:16Z")

</div>

A trivial one that bugs me

In lists of Events where a Date is included why can we not have the  
leading zeroes included ie my preference is for 01 May 1920 not 1 May  
1920. This would then mean all columns of dates would line up and look  
as if it were meant to be.  
01 May 1920  
10 May 1920  
not  
1 May 1920  
10 May 1920

Phil

---

<div class="post-metadata">

**Author:** ![emyoulation](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/emyoulation/32/67_2.png) [@emyoulation](https://gramps.discourse.group/u/emyoulation)\
**Post date:** [April 2, 2024, 4:53pm UTC](https://gramps.discourse.group/t/roadmap-for-v5-3-correction-6-0/5203/14 "2024-04-02T16:53:54Z")

</div>

But to align properly with leading zeroes (or leading spaces) then the font would have to be a monospace rather than a proportional one as well.

&nbsp;9 Jul 1920  
01 May 1920  
11 Apr 1920

```TEXT
 9 Jul 1920
01 May 1920
11 Apr 1920

```

And, to my eye, monospace fonts cheapen the appearance of the rest of the text.

---

<div class="post-metadata">

**Author:** ![jacrider](https://avatars.discourse-cdn.com/v4/letter/j/b5a626/32.png) [@jacrider](https://gramps.discourse.group/u/jacrider)\
**Post date:** [April 2, 2024, 5:22pm UTC](https://gramps.discourse.group/t/roadmap-for-v5-3-correction-6-0/5203/15 "2024-04-02T17:22:57Z")

</div>

I can’t really see that most of these ideas would have any impact on my  
usage, although I might find a use for some of them if they are implemented.  
However, I do see a need for either better documentation of the place  
structure or enhancements to it. The biggest problem I’ve encountered  
is when I’ve attempted to specify a date range in the Place Name Editor  
dialog, maybe because I haven’t used it consistently enough. As an  
example, I tried specifying the date range “after 11 Nov 1889” for the  
state Washington and “from 2 Mar 1853 to 11 Nov 1889” for the territory  
Washington, but I did not specify a date range for places enclosed by  
one or the other (although I sometimes listed both places on the  
Enclosed By tab with different date ranges for places associated with  
events that happened before Washington became a state). A consequence  
was that for events with no date (which I frequently do for burials as  
well as events that I don’t have a date for), the place will be  
displayed with a “?” in the name where the state would normally be.  
Also, in the Place index in the Narrated website, “?” appears in the  
name for some of the same places.  
I would like to do a better job of tracking changes to places through  
time than I have, but problems like this make me wonder if it is worth  
the effort.  
Related to places, I think a few improvements could be made to the place  
pages in the Narrated website. I would like to see the place type added  
to the pages and I would like to see links included more consistently  
for places that appear on the page. For example, Enclosed By and Place  
Encloses are sometimes shown with links, but not always, and none of the  
places in the first part of the page (City, County, State/Province,  
Country) have links. I suspect but am not sure that the problem is that  
places of custom types are handled differently.

---

<div class="post-metadata">

**Author:** ![Mihle](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/mihle/32/612_2.png) [@Mihle](https://gramps.discourse.group/u/Mihle)\
**Post date:** [April 2, 2024, 5:25pm UTC](https://gramps.discourse.group/t/roadmap-for-v5-3-correction-6-0/5203/16 "2024-04-02T17:25:06Z")

</div>

I support improvements to types, places, grouping of sources/citations.

When it comes to grouping of sources, for what I currently have used until now, It wouldn’t matter if its actual layered sources/citations, or if its only organisation. Any of them would be better than now.  
It would let me have the plenty sources I have that is the same magazine/journal grouped together in the list 🙂

When it comes to place enchantments:  
Would it be possible to put multiple coordinates on a place with date ranges, or make places inherit coordinates if they have none/an option is selected?  
Even having to put in some word in to the coordinate field to mark it so it inherits, would be fine.

> [@emyoulation](#):
>
> But to align properly with leading zeroes (or leading spaces) then the font would have to be a monospace rather than a proportional one as well.

I agree with having leading zeroes. No matter what the font is, I think it would look better than without the zero, in my opinion.

Not related to Gramps, but:  
Maybe it would be useful for feature requests on Mantis to have an upvote button(“I want this too” button)? I try to summit there when I remember things when they arent there already.

---

<div class="post-metadata">

**Author:** ![GeorgeWilmes](https://avatars.discourse-cdn.com/v4/letter/g/c57346/32.png) [@GeorgeWilmes](https://gramps.discourse.group/u/GeorgeWilmes)\
**Post date:** [April 2, 2024, 5:27pm UTC](https://gramps.discourse.group/t/roadmap-for-v5-3-correction-6-0/5203/17 "2024-04-02T17:27:11Z")

</div>

1. Could there be a new category view oriented around research? Think of how the “Combined View” within the Relationships category. It is essentially a combination of things that were already visible in the existing Relationship View (with the use of gramplets for Details, Children, Events, etc.), yet the new view makes it possible to see more at once and open things with a single click rather than a double click. It’s also a more interesting layout rather than just lists. While the Combined View is centered around a person and their relationships, it makes me wonder if there could be a new category view centered around a research topic or goal, including relevant repositories, sources, citations, and notes.

2. As a user who is comfortable making small changes to the code, I would like to see ways to make built-in things easier to customize. For example, adding a column to the Person category view involves changing a number of files, after first figuring out which ones need to be changed. There is, of course, the alternative of creating a completely new view as an addon, but in this example that would mean reimplementing 99% of the original view, and having to maintain all of that redundant code myself. Another idea along these lines would be to enable new types of addons, for example being able to add tabs in the lower half “notebook” section of the editor dialogs.

3. Is some large-scale review of the outstanding feature requests needed (and perhaps dreaded)? If so, could it somehow be assisted by AI? By the way, of the approximately 1,400 open feature requests, only half are “confimred”, while most of the other half are “acknowledged”. What’s the difference, in practical terms?

---

<div class="post-metadata">

**Author:** ![Nick-Hall](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/nick-hall/32/95_2.png) [@Nick-Hall](https://gramps.discourse.group/u/Nick-Hall)\
**Post date:** [April 2, 2024, 5:45pm UTC](https://gramps.discourse.group/t/roadmap-for-v5-3-correction-6-0/5203/18 "2024-04-02T17:45:16Z")

</div>

> [@GeorgeWilmes](#):
>
> Could there be a new category view oriented around research? Think of how the “Combined View” within the Relationships category. It is essentially a combination of things that were already visible in the existing Relationship View (with the use of gramplets for Details, Children, Events, etc.), yet the new view makes it possible to see more at once and open things with a single click rather than a double click. It’s also a more interesting layout rather than just lists. While the Combined View is centered around a person and their relationships, it makes me wonder if there could be a new category view centered around a research topic or goal, including relevant repositories, sources, citations, and notes.

Yes. Good idea. We should probably [start a new topic](https://gramps.discourse.group/t/new-category-view-oriented-around-research/5912) to discuss the details.

---

<div class="post-metadata">

**Author:** ![Nick-Hall](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/nick-hall/32/95_2.png) [@Nick-Hall](https://gramps.discourse.group/u/Nick-Hall)\
**Post date:** [April 2, 2024, 5:48pm UTC](https://gramps.discourse.group/t/roadmap-for-v5-3-correction-6-0/5203/19 "2024-04-02T17:48:45Z")

</div>

> [@GeorgeWilmes](#):
>
> Is some large-scale review of the outstanding feature requests needed (and perhaps dreaded)? If so, could it somehow be assisted by AI? By the way, of the approximately 1,400 open feature requests, only half are “confimred”, while most of the other half are “acknowledged”. What’s the difference, in practical terms?

Yes, but we would need a volunteer.

“Acknowledged” probably means that someone has read and understands the request. “Confirmed” probably means that they think it is a good idea. I’m not sure.

---

<div class="post-metadata">

**Author:** ![Nick-Hall](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/nick-hall/32/95_2.png) [@Nick-Hall](https://gramps.discourse.group/u/Nick-Hall)\
**Post date:** [April 2, 2024, 5:50pm UTC](https://gramps.discourse.group/t/roadmap-for-v5-3-correction-6-0/5203/20 "2024-04-02T17:50:31Z")

</div>

> [@Mihle](#):
>
> Maybe it would be useful for feature requests on Mantis to have an upvote button(“I want this too” button)? I try to summit there when I remember things when they arent there already.

Perhaps we could use this forum somehow? One topic per feature request in a new category.

[Next page](https://gramps.discourse.group/t/roadmap-for-v5-3-correction-6-0/5203.md?page=2)
