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.
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.
There is something to be said for the idea of understanding the learning curve of a user-base.
Gramps users and genealogy enthusiasts are typically older and with less IT system experience and may not appreciate the volunteer ethic that open-source has.
Therefore I suggest a category of “Getting started” where the basic are laid out in pinned informative narratives like “what is open source?”, “who are the players in Gramps?”, “how to consume Gramps across your family?”, “how the new genealogist typically advances”, “where to find helpful references”, “choosing an operating system and hardware”, “how to contribute (even in a small way)”, etc.
These could be written in an easy to consume way (leading to easier automated translation) and may set the expectations of most people (leading to more community).
Each of these narratives can and should stand alone, be versioned, printable and copyrighted, and contain copious references to external references for the new users to determine their pathway forward. They could be located on the Gramps-project web site and the Discourse category can point to them and their revisions.
It might need a while to get it together but it might allow our existing infrastructure to be better utilized and draw-in less technical users who might otherwise be scared off by devs, builds, and patches.
Just my 2c worth.
Tutorials and backgrounders!
Then we can see how the forum categories should be changed from time to time.
Brian