Adapt has been largely stable over the last 5 years, with the bulk of effort going into either mycroft-core, or padatious (a c++ ML-based intent parser). Given this stability, it makes sense to finally make a push for 1.0, opening the way to begin development on 2.0, without the baggage of maintaining backwards compatibility.
As part of the effort to get to 1.0, we'll have 3 major workstreams
There are currently 4 open PRs, languishing as far back as 2017. We should be able to complete or close these out quickly.
There are currently 30 open issues against Adapt. I'd like to triage these on the following dimensions
- Needs reproduction
- Can't reproduce, won't fix
- Reproducible, won't fix
- Reproducible, scheduled|in progress
- Fixed
- Deferred post-1.0
I'd also like to add the label of Adapt: Road to 1.0.0
to each of these issues, once they've been triaged.
Speficially, how/why we're transitioning to 1.0.0 to stable/supported, what the future looks like for 1.x, and decide where to branch for 2.0 development.
A couple of things I would like to see addressed...
First, the comments and docstrings need some work. Example,
What is a key? what is metadata? how are they related? Comments should not be pseudocode. We can all read the code. They should give insight into what the function is doing from a business perspective, and why? This is a somewhat complex library. Some of the code is hard to follow without knowing the context of what it is doing.
The IntentBuilder in its current form results in a lot of duplicate code. Look at the weather skill. there are several intents with "one_of('Forecast', 'Weather')", "optional('Location')", "require('Query')", etc. Isn't there a way this can be done without all the duplication? Also, some of the bigger intents can get very large and somewhat complex. Trying to follow the chain of function calls can be difficult.