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
:doc:`contributing` to learn about our expectations for submitting changes and
improvements.

Bug Reports
+++++++++++

If you think you have found a problem, then we want to hear about it!

We keep track of issues via our
`GitHub repository <https://github.com/mu-editor/mu/issues/>`_. You'll need to
have an account on GitHub (joining GitHub is
`very easy <https://github.com/join>`_) in order to submit such feedback.

When you `create an issue <https://github.com/mu-editor/mu/issues/new>`_ 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". ;-)

Coding
++++++

The first thing to do is follow the instructions for :doc:`setup`.

You should read the explanation of :doc:`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
``logic.py``.

If you'd rather try something more substantial, why not explore the
`list of currently open issues <https://github.com/mu-editor/mu/issues/>`_,
fix one of them and create a pull request for your solution?

Translations
++++++++++++

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
:doc:`translations`.

Documentation
+++++++++++++

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 <https://codewith.mu/>`_. 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
:doc:`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 <https://www.fastcompany.com/40435064/what-alan-kay-thinks-about-the-iphone-and-technology-now>`_

How do we know what "the real thing" is in the context of a code editor for a
beginner programmer? That's where :doc:`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.
