Can we create a separate discourse for dev, wiki, etc technical conversations?

Feedback
1

It would be nice to have development conversations in discourse, but I wouldn’t want to clutter the this predominately user-oriented one.

The other option is to use the github issues for technical conversations. The bug tracker can remain as it is.

Just looking for a place to have technical conversations without having to first make a Pull Request in github.

What do you think?

2

Why isn’t the Development section sufficient for the technical conversations/discussions that have already taken place in the past here?

Should I add a subsection to Development called maybe “Technical” as we currently have sub section called Roadmap / Beta Testing / Bug triage & Translation?

Another option is to use a tag to mark the post as “technical” !

As for cluttering discourse people will read what they want…and it is better to have everything in one place!

From my perspective I’d rather not have another place to manage!

3

Discourse allows group assignments for different sections. And members can opt out of being notified in different categories. So, functionally, the same thing could be achieved with one of those.

However, a significant number of subscribers to the developer mail list have indicated that will not use a Discourse forum. So we still have a dedicated Developer conversation forum… albeit one without the bells and whistles of Discourse. (If the conversation needs screen captures or illustrations, it can always be diverted to GitHub, the wiki or here.)

4

Another option is GitHub Discussions.

Perhaps they would find a GitHub solution acceptable?

Currently the mailing list is our primary developer communication method.

5

I prompted Perplexity to explain how to mute a Category by default… changing behaviour to an Opt In instead of an Opt Out.

does the discourse forum have an “opt in” feature to complement the “Opt Out” user preference?

it replied about making Users invisible instead of postings. Requiring a followup prompt:

This is not asking about users being invisible. It is asking about Categories of postings. discuss how an Admin of Discourse can set a single Category (or subcategory) to Muted by default

An admin can mute a specific category (or subcategory) by default using the “default categories…” site settings so that all users start with that category set to Muted.

Option 1: Per‑category default (recommended)

This lets you mute one category or subcategory for all users (or new users) by default.

  1. As an admin, go to Admin → Settings → Users.​
  2. Find the settings starting with default categories ... (e.g. default categories muted).​
  3. In default categories muted, add the category or subcategory you want muted by default.
  4. When you save, Discourse will prompt whether to apply this change to existing (active) users or only to new users; choose the option you want.

From that point, all affected users have that category’s notification level set to Muted until they override it themselves.

Option 2: Group‑based defaults (for specific user groups)

If you only want some users to have a category muted by default:

  1. Go to Admin → Groups → (pick a group) → Manage → Categories.
  2. For the target category or subcategory, set the notification level to Muted for that group.​
  3. Enable the option to apply this change to existing group members if you want it to take effect historically.​

Discourse will then keep that category muted by default for members of that group, subject to how you configure “user override” behavior.

6

Because too many people view it and I think they probably don’t want to.

The mailing list is not a good place for having modern discussion, including images. I think conversations about technical issues (development and wiki management) are distracting for users that are looking for discussion about how to do something using Gramps, or looking to talk about genealogy.

Github discussions would work for me.

Or I can continue to use The Development topic.

7

I think if you haven’t contributed to the Gramps source code for a few years, then your opinion about where to have discussions about developing Gramps today should be taken with a grain of salt.

@Nick-Hall can you turn on github discussions? At least for a trial.

8

The enthusiasm and drive of Developer can burn out. But we have to try to rekindle their interest.

And the last couple years of progress in AI tools have been firing the imagination of a lot of users without programming skill. So our need for people with the skills to review code is going to explode. I’m hoping that things like the FamilySearch integration and simplifying the personal beta test publishing for addons will tempt some of our fallow developer back to Gramps.

9

Or maybe try to attract developers and seasoned researchers from other parts of humaniora research to Gramps by actually providing open‑source, open‑data, interchangeable, loss‑free formats?