Rhasspy roadmap?

Maybe we should come up with a clear roadmap of future developments?

  • architecture : splitting services? Which ones?
  • protocol : MQTT? with Hermes?
  • intents : grammar based slots?
  • asr : Kaldi GrammarFST on the fly decoding? Online decoding? Deepspeech?
  • tts : NanoTTS instead of PicoTTS?
  • doc : Wiki to share intents? Slots?
  • dev : Github project? Organisation?

Indeed, and streamlining development on GitHub with an organization, project dashboards, a proper release process and so on will help tremendously with tracking all this information.

@synesthesiam I’m still convinced we really need this rhasspy organization. It will make it much easier for you to delegate tasks, especially in the project management domain, and a roadmap is an important part of that.


+1 for a Development topic to discuss this in depth.
+1 for a Github organization to centralize repos, project and roadmap

1 Like

OK, I transformed the rhasspy GitHub account into an organization and invited you both (@koan and @fastjack).

What do we do about repositories? Should I fork existing ones on my account, or create new ones and deprecate the old ones? I’m thinking only the new service repos should be transferred for now.

Yes, keeping the ‘main’ rhasspy repository where it’s now for continuity and transferring the new ones to the organization seems sensible.

1 Like

Why forking repos like kaldi, pocketsphinx and such ? You will have to update them everyday to keep them up to date ? Why not just keep them as requirements ?

1 Like

I meant the repos for the various Rhasspy services, like rhasspy-nlu-hermes, etc.

I think those should just be relocated, so I can delegate more to the community through the GitHub organization. Unlike Spiderman, I’m not sure I can handle the great power and responsibility :spider:

My proposals for this roadmap :

  • Rhasspy service mesh : I’ll let you imagine the benefits
  • NLP ?
  • centralized logging
  • Use of tool to keep packages up to date (greenkeeper …)

Moved over most of the repos. Here’s a list of the current services.

Do you know a good solution for Python? This is an excellent task to add to our work-in-progress CI pipeline.

On which repository should we create a project with the roadmap?

How about the rhasspy-services project? I can re-name it to something like rhasspy-roadmap or rhasspy-planning. Thoughts?

It looks like project can be at organization level also. Wouldn’t this be easier?

Also, the organization is currently called Michael Hansen :wink:

Will the current rhasspy repository keep its name when it’s migrated later to the rhasspy organization? Or will it vanish after the mqtt rewrite because we’ll have rhasspy-server, rhasspy-client, rhasspy-standalone and so on? If the latter, we can use the rhasspy name for the docs, roadmap, and so on.

1 Like

Didn’t know that. An organization-wide project seems better for discoverability then :slightly_smiling_face:

I added a Roadmap project. To be filled :slight_smile:

For now we’ll probably have to refer to issues in the rhasspy repository too in this project.

@synesthesiam I guess you could also add new colums or even new projects for new major releases, but we’ll have to start somewhere, so the To do/In progress/Done columns should be a good start.


Thanks, @koan! I’ll be adding more to it as I can.

I’ve successfully tested the rhasspy-dialogue-hermes service now with microphone, wake, ASR, NLU, TTS, and playback services. There are still lots of gaps to fill in, like a rhasspy-wake-snowboy-hermes service.

I split out the web UI into a rhasspy-web-vue and rhasspy-server-hermes project. The former is just the Vue html/js/css stuff, and the latter is a (partially done) web server that talks MQTT/Hermes on the back end.


Do we want ingress support in the AddOn?

I added a few items to the Github roadmap project :slight_smile:


I hadn’t heard of ingress before. Looks like something we should be able to support. That would definitely make it easier for users who have SSL, no?