Sylvia recently took on the task of updating the Mycroft Docker image. This provides a containerized way to run Mycroft on a diverse range of platforms. She also developed Mycroft Web UI, a very simple web interface for interacting with your Mycroft instance. Most recently Sylvia released the Travel Time Skill, providing real-time estimates for driving utilizing the Waze API.
Her contributions to Mycroft have extended beyond code. Sylvia has been regularly filing bug reports and providing updates to documentation across a range of repositories. As well as helping other Community members in Mycroft Chat and Telegram group.
Through this blog series we are meeting some of the people that make up our Open Source Community. To hear about what they have built with Mycroft, and why they got involved. We are so grateful for the time and expertise Sylvia has been able to share with the Mycroft Community, and excited to hear more about her and her work.
Hi Sylvia, thanks for taking some time out for us. To kick things off, can you tell us a little about yourself?
Yeah, sure. I’m Sylvia van Os (TheLastProject on GitHub, SylvieLorxu on Twitter). I’m a Dutch citizen with a passion for Open Source who loves writing code, especially Python. I’m currently employed at Sue B.V., a Dutch Linux consultancy firm, where I help a wide variety of companies as a Linux system administrator. In my spare time I can often be found making issues and pull requests on GitHub or playing video games.
For those who are curious: Lorxu is lojban for fox. In the Netherlands, “tussenvoegsels” (the word “van” in my last name) often gets shortened, so many IT systems give me usernames such as svos. Vos also happens to be the Dutch word for fox. This, together with friends often calling me Sylvie (as a less formal version of Sylvia), created the username SylvieLorxu.
You’ve contributed to Mycroft in such a broad range of ways, how do you decide what you’re going to work on?
I’ve been in the Open Source world for a while and I learned that the easiest way to keep things from becoming a chore is to focus on fixing your own problems first. So, if an issue affects me personally, I am more likely to take some time to try to fix it myself. However, if I don’t have time or feel I lack the knowledge to fix it, I’ll instead create an issue. And sometimes I just feel like coding, so I may pick up random issues on the issue tracker to see if I can solve them.
A number of your projects use Docker, what do you like about it and why do you think that is useful for a project like Mycroft?
The main benefit to Docker is that everything is pretty self-contained. It saves users from having to deal with installing and configuring dependencies, because you basically just provide a script that does all that for them. While Docker isn’t a be-all end-all solution to all problems, it often does simplify the setup process for end users and lowers the risk of things not working because something on the host system is configured differently from how you expected it to be.
Outside of Mycroft, I know you run an open source project yourself. What is Pext and where can people find it?
Pext stands for Python-based extendable tool. It is designed to be a simple front-end that is basically no more than a search bar and a list of entries, with multiple pluggable back-ends changing the behaviour. This makes it a flexible little application usable for many tasks such as password and clipboard management, picking an emoji or even listening to Internet radio. It is currently available for Linux, macOS and Windows.
Pext’s homepage is on pext.io, the code is on GitHub and translations are managed on Weblate. Our community is reachable on Telegram and Matrix and we’d be happy to welcome new users and contributors of any type.
Often people presume that open source contributions have to be code, however there are so many important ways that people can add value to projects. Why are non-code contributions so important for open source projects?
The main reason any type of contribution is important is that everything costs time and there’s always only a limited amount of time. Especially in the Open Source community, many projects tend to be someone’s hobby, so the developers are more likely to focus on the things they find most fun (which is often coding), causing other areas of a project to suffer.
The main non-code contribution types I often think of are translations, documentation and filing issue reports or suggesting improvements.
The importance of translations is often missed to developers, as most of us are able to speak English. However, many people actually don’t speak English and of those who do, a significant amount doesn’t speak it as their first language. This means that projects are often hard to use or plain unusable to many potential users unless their language is supported. I genuinely believe translations are one of the most important ways of ensuring as many people as possible can use a project.
Secondly, documentation. While we can’t expect non-technical people to write technical documentation, they do have one benefit over the developers: they don’t already know everything about the code. As a developer, you often know many details about the application or used technology and can easily forget to document something that seems obvious to you, so other people adding or updating documentation can be very helpful to improve the quality.
And last, but definitely not least, reporting bugs or feature requests is a hugely important thing. I see many people give up on some tooling because they run into a bug or miss a feature. Often, this tends to be something that was never reported by anyone and that the developers would be very willing to fix. So please report any issue you have, creating a GitHub issue is really one of the most important things you could possibly do without coding.
What advice would you give to someone who wants to contribute to Mycroft or another open source project?
The most important thing is that no contribution is too small to matter. In fact, many small fixes, like just fixing a documentation mistake, can end up saving people many many hours of frustration.
Don’t be afraid that your improvement won’t be good enough to matter, most projects are literally waiting for any contribution they can get. Just make sure to read a project’s README and any contributing information you can find.
If you’re still unsure about something, find the project’s chat channel and ask, preferably stating what you already tried to figure it out. Do remember that most people in Open Source projects are volunteers with their own daytime job, so answers are often not instant.
If you are looking for ways to contribute to Mycroft we need all types of skills and experience. Take a look at the many ways you can help at: http://mycroft.ai/contribute
Gez is the Director of Developer Relations at Mycroft. He comes from the land down under, has a strange love of crocodiles, and one day hopes to play the ukulele. If he’s not hanging out in our Community Chat and Forums, he is probably getting lost in the bush.