Category Structure

I have temporarily closed this topic because the tone of the discussion was getting slightly unpleasant. Please read the FAQ/Guidelines, especially the section Be Agreeable, Even When You Disagree. Let’s keep this a civilized place for discussion.

I’ll open this again shortly.

1 Like

I was think about a category for this myself. The whole idea behind creating this forum was to open discussion to a wider audience. That includes making the development process more transparent and encouraging user feedback. My post about PR #941 was the first step in this direction, and I will probably create a “New Features” category. This could contain topics for selected pull requests with screenshots to help explain the proposed changes.

The GEPS is often too technical for the average user and I don’t expect many users to browse through pull requests for the same reason. The bug tracker roadmap is really only used for bugs, not new features. We have a roadmap on the wiki, but I don’t think that it is up to date at the moment.

How would a “New Feature” category be different than “Development”?

As I understand it “Ideas” is a place to throw an idea out there for debate and see if there is a sense that the idea should be implemented. Your Date quality in GEDCOM exports seems to fit that category. The idea has been proposed, should we do it?

The PR #941 Age Stats is well underway and I see the “Development” would be where this would be discussed. Unless you see the Development category to be more on the technical side; more of the How-To.

I am not throwing water on the idea just entering the discourse.

“Ideas” is certainly the place for anyone to throw out new ideas.

I see “Development” more for technical discussion. Once a developer would like to implement an idea they should discuss the design first and get approval before coding.

What I was hoping to do with the “New Features” category is to show users new features that are currently being developed for the next release and get some feedback. PR #941 was just the first example. The idea is to make the development process more visible to users. Developers already use GitHub for this purpose.

I agree that there is some degree of overlap though.

The quality modifier for compound dates in GEDCOM exports is more technical. We are proposing to remove a feature in order to increase compliance with a standard. This should also be of interest to anyone who uses GEDCOM exports though.

2 Likes