The supported Genie skills are developed in the thingpedia-common-devices Git repository. The repository contains the design files (manifests, primitive templates), the JS backend of each skill, the manually annotated evaluation sets and paraphrase sets for training, and the scripts to train custom natural language understanding models.
We recommend following the instructions in the repository to learn how skills are added and tested, and how we train custom models for testing. You will need to train your own model to see the effect on the conversations of any change you make. We also recommend reading the Genie Guide to learn how Thingpedia skills are developed.
Once you are ready to share your improvements, please file a Pull Request. The PR will be reviewed by an Genie developer and then, if everything is in order, it will be merged. After the merge, a new official model will be trained and the updated skill will be published in Thingpedia.
When developing for Genie, please adhere to the following guide.
To develop a new feature or bug fix, you should fork the repository and create a new branch, based off the master
branch, dedicated to that feature. By convention, feature branches start with wip/
.
Please separate your changes in individual commits corresponding to different logical parts of the feature. Each commit should either fix a separate issue, or add a new separable module. Commits should be reviewable individually, and ideally individually testable (this might not be always possible).
After you're done with the feature, you should submit a Pull Request. Integration tests will automatically run, and the PR will be reviewed by a member of the Genie team. You must make sure that all tests pass: PRs will failing tests might not be reviewed, and will not be merged.
To simplify and speed up review, we ask all contributors to write properly formatted commit messages. The commit should start with a subject line containing the subsystem, followed by a colon, followed by a short description of the change. The body of the commit message should describe the issue being fixed, the actual change, and the purpose of the change.
We recommend reading this excellent guide to write good commit messages.
We strive to ensure a consistent code style in our codebase. For Javascript, we use 4 space indent, with no tabs. All statements should use a semicolons. Braces should be used as needed for control statements.
Most of the style rules are enforced by eslint
; you can run it with yarn lint
to check your style, and it will be run automatically when you submit a PR.
For Python, we follow PEP-8, with a 100 character maximum line length.