Several responses here, some policy/ethics some technical. Let me start with the technical since I think those are a little more straightforward:
i think msm overall needs some changes:
allow to choose default skills
allow blacklisting some skills
make auto update configurable per skill```
MSM and the mycroft-skills repo definitely aren’t perfect or general consumer ready. But before the repo existed discovering skills was very difficult. Once it existed, instructions were still difficult. Now there is a consistent way of installing – “hey mycroft, install Whatever”.
Recently I made the “default” skills configurable by the default skills repo, including platform dependent defaults. More on that below in the Policy discussion.
Disabling the auto-update is simply too early, IMHO. Basically, every skill today is at the “minimum viable product” level and needs to improve. Making the process of improvement slower today would be a hinderance, not a true help to the community. There is a path to not auto-update (see above), so I living on the edge during the alpha phase should be expected. When I walk onto a construction site I expect to wear a hardhat and look out for the frontloaders driving around, and that is where Mycroft is today.
I could easily add a mechanism to disable MSM for now. But I really don’t want to create user interfaces to do that, it is a bad precedent that would interfere with the better solution outlined above. So if you are doing it via a keyboard, just rename msm/msm to something like msm/msm-manual. Just my $0.02, but I’d be willing to accept a mycroft.conf setting PR if you want to invest the effort in implementing it.
you need to specify a reason before “banning” a skill
Well, it was called “Evil skill”. And you didn’t hide that the purpose of it was to create discussion, not to do anything useful. Thank you for linking that PR to this discussion – that was what I suggested be done.
Another question, if someone were to make “paid” skills, would these be rejected?
Nope! That is absolutely intended to be supported and I’ve talked for at least a year about the idea of including skill fees in the metadata to describe a skill. For today, the technical hurdles of making a “paid” skill are what make this tricky. Here are the things I see as difficulties and where I want to go with them:
- You can’t safely “hide” things like API keys. I want to allow home.mycroft.ai to act as a safe for developers so they don’t have to embed their API secrets in their Python code which is clear for everyone to see. No work is actively underway for this yet, just planning.
- Devs can easily allow users to perform OAUTH easily – e.g. to get authorized access to their Google Calendar. We are working on that right now.
This is the most debatable bit. What are the lines that exist for Mycroft? Where do we declare “acceptable” and what what isn’t?
Several months ago I officially handed over the mycroft-skills repo to the Mycroft Community. I create a board of 5 people to manage it for the community and, most importantly, to create the mechanisms for managing it as a Community. I.e. how big should the board be, how do we pick future board members, what are the mechanisms for submitting a skill, what are the guidelines for nameing/tagging skills, …
In addition to that, we have a lot of stuff to decide that is even more nebulous. How do we deal with legal issues, especially since we are an international system? Are there guidelines for NSFW/Obscene and if so how do we define what that means – or how do we avoid having to define them? I think this last point is probably worthy of an entirely different post and open debate. In general, these sorts of decisions will be the “constitution” for the Mycroft ecosystem and I want these decisions to be made thoughtfully.