New "Best Practices" category

Dear forum members,
The Gramps users constantly have questions about how to best organize various types of records in the Gramps program. Personally, I feel that the forum lacks a dedicated section for Best Practices from experts in the program, perhaps even from its creators. When I started using the program, I organized data in a way that I devised from scratch. However, as I learned more about the program, I constantly changed and improved this approach. But it still has many drawbacks. For example, I only recently started using the Residence event because I was not aware of its existence before, and I already have 8000 individuals in my database.

I could share several pages of various documents, and I can also translate them into English for convenience. These could include vital records such as birth, marriage, death, confession registers, and census lists. Someone could then create several Best Practices posts based on these documents. Others could share different types of documents. This way, we could create a very valuable practical guide for users.

Also, I think each Best Practice guide and it’s discussion should be somehow separated from each other. Perhaps even make the Best Practices section only for reading, with discussions taking place in other sections, such as Ideas, Help, etc.

1 Like

Discourse is the wrong place for such documents. Mostly because it lacks structure to organize the material so that it can be found. And the clutter that grows around everywhere.

A structured outline belongs in the wiki.

There will also be significant disagreement over which approach is “best” for anything. One of Gramps strengths is that it is not dogmatic about process. (Which is why there are multiple frontends too: the Gtk GUI for Desktops, the CLI, Gramps Web for browsers, the API, SuperTool for direct manipulation, a multitude of import tools, gramplets, et cetera)

1 Like

I agree also that it will be difficult to agree on what is best. Yes we should use the system as it was designed, but there is many ways that the user can do this based on the outcome they want. Example: many times it is suggested to use attributes to store the info. There are even Forms designed to do this, however if you intend to upload the information via a gedcom file, this does not work because the attributes are not included. Therefore the “best practice” in this case is to put the info some other place. That is why GRAMPS is good, because it is flexible. The intent is written into the help files and with some thinking out side the box we have all made it work for us. I would suggest to every new user, to read the help file for each screen you open. I wish I had done that right at the start.

1 Like

@emyoulation @Davesellers I agree with both of you. I just feel that there is a lack of some structure for users that would organize their knowledge and allow them to choose the same optimal usage scenario. However, it’s challenging to determine the specific structure and how it could look due to the extensive flexibility of the Gramps program.

1 Like

Now that the v5.2 has been released it may be time to start some discussions. I’ll list a few topics that may be of interest:

  • How should we handle multi-layer citations?
  • What is the best way to store citation urls and access timestamps?
  • Do we want to support the Gedcom non-event structure?
  • Should conflicting evidence be stored as multiple events or maybe use attributes or some other method?
  • Do we want to introduce a persona concept (Gedcom ALIA tags)?
  • How do we want to model ships? As places or a new object type?
  • Would time dependent facts be useful? If so, should they be distinct from attributes?

The answers to these questions could affect the best practices that we recommend.

There is also the bigger question. How close do we want to keep to the Gedcom standard?

We probably want to start several topics to discuss these.

1 Like

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