NOTE: I edited and added a couple links, but haven’t changed the content)
Here is my view of the “Mycroft Skill Lifecycle” and how it works/will work in the Mycroft ecosystem.
##Ideation (stick with me through that term )
- A user or developer would post on the general “Skills Development” forum a request or idea. “I’d like to control my coffeemaker!”, “I’d like to control my breadmaker!”
- Discussion would be held there until it starts to solidify.
“Maybe we could support this widget from Xyz that switches outlets on and off”
- As idea for a Skill gels, all interested in the skill would move discussion to a forum topic (e.g. a new topic in the Skill section here). This will likely happen when a developer is ready to take on writing the skill.
“I’m going to take this on, everyone. Let’s take this discussion to the ‘Skills > Xyz Control’ forum topic.”
Optionally you can chat in Slack and such, but doing it in the forum archives the discussion nicely for future reference.
Skill Development (open version)
- Under the forum topic, potential users would discuss what they want and need the skill to do, vocabulary to use, etc. Developers would coordinate and hash out details. This will continue throughout the process.
- Someone will host the skill development on GitHub as the main repo under their user account. The posted Skill Template can be used as a starting place.
- Under the mycroft-skills GitHub repo a link to that new Skill’s repo would be created. (This is a submodule reference to the Skill repo’s master branch, actual dev work would be done within the Skill’s main repo using whatever branching and labeling structure the project participants like.)
- Under the subfolder, a README.md would be created based on the template provided in the template Skill provided by Mycroft. It would include plans, development status, etc.
- During development any user or collaborator can potentially pull down the code and install on a device by hand by simply pulling the it into the user Skill folder on a Mycroft device.
NOTE: After some amount of time we might move non-working Skills into and “abandoned” folder to keep things clean.
Skill development (proprietary version)
- The organization would pull down the skill template
- Code would be developed and tested internally using their resources
NOTE: Skills can be tied to a custom platform via metadata, thus only appearing in the Store when a user has that platform. E.g. a skill to check how many eggs are in a Samsung refrigerator.
- Once a Skill is deemed “ready for the world” by its development team, they will fill out manifest from the template included in the Skill to describe the skill in the store.
- A manifest would included things like long and short description of the skill, sample phrases it handles, logo graphics for the store, required required device capabilities or platforms, etc.
- The Skill must include basic unit-tests for automated testing (phrase parsing, etc)
- The Skill repo URL (open development) or zipped package (proprietary development) is sent to Mycroft for validation along with a point of contact
- Mycroft reviews the Skill (automated scans, pip-package review, code review looking for malicious behavior, verification that all info needed has been filled out). Feedback is provided to point of contact. If changes are needed, resubmission would occur until things look good.
- Once validated, a Skill package is created and placed in the Skill Store
- A user logs in to their account (currently via https://cerberus.mycroft.ai), entering their Profile. Each Profile is associated with registered Mycroft Devices.
- When the user enters the Skill Store, they are presented only with Skills that are supported by at least one of their devices. Skill developers describe the supported devices via several mechanisms:
- Specific devices: “Ford ABC 123”
- Device capability descriptors: “requires screen”, “requires screen-rgb”, “requires bluetooth”, etc.
- User can select a Skill to get information about it. This would show the logo, description, example phrases, etc. that were provided when the Skill was submitted to the Store.
- User clicks “Install” and it would be added to the “Available Skills” for that Profile.
- By default, Skills would be pushed to all devices associated with the Profile that support it. User can also uncheck the Skill for specific devices, e.g. removing “Bank-of-Kansas-City” skill from a shared device in the office.
- If the Skill indicates that it has configuration variables, a Setup icon would appear in the Available Skills list. Clicking that icon opens up a webpage allowing the user to set options. Additionally, options can be controlled/overrided at group (“Home”/”Work”) or specific device level.
- Skill settings can be changed at any time from this interface, and it can be uninstalled from a specific device or from the “Available Skills” list to remove from all devices.
OPTIONALLY: Device manufacturers can have specific skills pre-associated with their specific devices. They’d appear be in the interface just the same as installed Skills.
- When a Mycroft device next connects to the backend, a Skill change would be flagged.
- New/updated skills would be pulled down as a package and installed into the user Skill folder
- A ref-counted registry of PIP packages would be maintained locally. Any missing package would be installed, and any unneeded packages would be uninstalled.
- Settings will be synched up/down
User Feedback mechanism
- Any installed Skill can be rated (1-5 stars) by a user from the Profile’s Available Skills list.
- Comments can also be added, posted to the Skill in the Store. This will also be emailed to the Skill’s Point of Contact.
- Optional link from Skill in store would lead back to the Skill forum topic to provide bug reports, suggestions for improvements and feature requests for future versions (going back to Ideation).
Feedback is welcome!