Suggested First Steps¶
We love helpful, collaborative and friendly contributions!
If you would like to ease into contributing to Mu we’d like to suggest the following things to try out, depending upon your skills and interests.
If your contribution includes changes to code or documentation, you should read Contributing to Mu to learn about our expectations for submitting changes and improvements.
If you think you have found a problem, then we want to hear about it!
When you create an issue we expect certain pieces of information from you:
What you were doing (including all the necessary steps needed to recreate the situation you encountered).
What you expected to happen, what actually happened and why you think this difference is problematic.
Attach a copy of the logs generated by Mu (click on the cog icon in the bottom-right corner of Mu to display these logs, click on the logs and use CTRL-A to select all, then CTRL-C to copy and CTRL-V to paste the contents into the issue).
Please try to be precise and provide as much information as possible.
For what are obvious reaons, I hope you can see why we’re unable to respond to issues that say some variation of, “when I click this button, it breaks”. ;-)
The first thing to do is follow the instructions for Developer Setup.
You should read the explanation of Mu’s Architecture to learn how Mu fits together. As of time of writing, Mu is a very small project with only around 4000 lines of Python code. However, it’s important to know where to find different aspects of Mu’s functionality and understand why Mu was put together in the way that it has been.
Assuming you’ve read and understood the architecture documentation an obvious
and simple way to get started is to change the code in
logic.py to suggest
an alternative (better) message of the day. When Mu starts up, so the user
sees that the status bar may contain textual messages from the application, a
“message of the day” is displayed. These messages are defined near the top of
If you’d rather try something more substantial, why not explore the list of currently open issues, fix one of them and create a pull request for your solution?
Mu uses Python’s standard libraries and tools to translate the application into other languages. If you are fluent in a language that is currently not covered by Mu, then we would love you to help by providing us with a translation.
Full details of this process can be found in our guide on the Internationalisation of Mu.
The documentation associated with Mu is not limited to addressing technical aspects of the editor (like the documentation you’re reading right now). Our documentation encompasses tutorials, how-to guides, learning resources and other non-technical information for our users.
Such non-technical documentation is a part of Mu’s website. If you are a teacher, learner or other interested party who wishes to contribute a tutorial, how-to or learning resource you should learn how to make such changes by reading the guide to Developing Mu’s Website.
User Experience Research¶
Our users are at the centre of everything we do. We have two sorts of user in mind:
Beginner programmers with little or no experience using a development environment.
Those who support beginner programmers: teachers, club leaders, parents and other mentors.
When it comes to teaching and learning sometimes you just have to do what the experienced person says: for example, the professional musician explaining to the beginner how to hold an instrument “correctly”. There is some notion of correctness that the experienced person understands is the best way to do something.
This also applies to learning to write code: we need to find ways to introduce the practice and conventions of programming in an effective manner. As Alan Kay said of Papert:
“He realized, ‘Oh, we could take the real content out here as a version in the child’s world that is still the real thing.’ It’s not a fake version of math. It’s kind of like little league, or even T-ball. In sports they do this all the time. In music, they do it all the time. The idea is, you never let the child do something that isn’t the real thing – but you have to work your ass off to figure out what the real thing is in the context of the way their minds are working at that developmental level.” – Alan Kay
How do we know what “the real thing” is in the context of a code editor for a beginner programmer? That’s where User Experience comes in and we would love contributions from professional developers, beginner programmers and teachers to make sure Mu is an effective educational tool.