Contribute to MDN Web Docs

How to start 

There are a few easy steps that you can take if you want to get started contributing.

You just need to 1) create a GitHub account,  2) pick a task to complete, and then 3) work at it! If you encounter any difficulties you are more than welcome to ask for help.

Go here for a detailed guide on how to get started!

Different areas you can contribute to:

There are multiple avenues you can take to contribute to MDN depending on your skillset and interests. Go here to start exploring ways to contribute!

Main ways to contribute are:

1. Fixing MDN content bugs
2. Reviewing MDN edits
3. Help beginners to learn on MDN

But there are many other tasks! Go here for more details on the different areas to which you can contribute

MDN events — get your community started in MDN

Organize an event (on-line in in-person) to help your community to  start contributing to MDN.

Before the event

Check out all the details on this activity here.

Discover the skills of your participants:

• If you don’t know the skills of your participants, you can ask them to fill out a survey about it. That would make selecting appropriate bugs and dividing the participants into group easier.

• Skills you can ask about: The most common bugs require skills in HTML, CSS, and JavaScript, but there are also some that require knowledge in HTTP, SVG or other technologies.

Search issues with appropriate labels within the quickest time label.

• Choose one closed issue that you can use as an example.

Example of a solved issue. 

Pull request for the solved issue

• Choose interesting open issues taking into consideration the skills of your event attendees —  we suggest that choose 1 issue for each 3-5 participants

• There is a label ‘good-first-issue’ on issues which are good for beginners, we suggest you start from those!

Get the bugs!

• You do not have to ask for the issue to be assigned to you, but you will need to comment with this standard sentence (please do this as near to the event as possible, to avoid issues being left for a long time or go out of date).

“I am taking this issue for an event, please do not touch it until 2 days after the event, which would take place X (add link to the event in the Community Portal)”

During the event (ca. 2:15 hours)

Introduction and set up

• Give a general presentation on MDN — Feel free to use this presentation (5 minutes)

• Talk about the  different kinds of contributions that people can make  (5 minutes)

• Ask people to create a GitHub account (10 minutes)

Fix the bug!

• Present the closed bug — give a step by step explanation: (15 minutes)
  • Explain how to search the GitHub issue tracker.
  • Give a step-by-step explanation on how the issue was solved.
  • Ask if there are any questions

• Divide your participants in groups based on their skills (you can use the doodle, and ask those that did not participate in it to join an appropriate group). (40 minutes)
  • Give the groups a list of issues to work on
  • Give them a timeline to work on the issue
  • Circulate between the groups and help them solve the problem
  • Once they solve the problem, ask them to let you know
  • Announce every time a group solves a bug
  • Once a group resolves an issue, they can choose another one

Submit fixes 

• After everyone has finished discuss one of the issues that were worked on, and show how to submit (10  minutes)

• Invite all the other groups to submit their issues (10 minutes)

• Check in with each group to make sure that all fixes were submitted correctly (10 minutes)

Wrap up

• Give prizes/acknowledgement to the group that finished first / finished more bugs/ had the best solution (5 minutes)

If you have the time to organize two events, we suggest you organize this follow-up event. (1 hour)

Presentation (20 minutes)

• Explain how an issue is reviewed

Review each other issues!

• Ask each group to review another group’s proposed fix. The group can comment on it and propose changes. (You can find more details on how this process works in GitHub here) (20 minutes)

• After that the issue goes back to the group which solved it. They can choose to accept or reject the changes made.  Give them some time to make any adjustment needed. (10 minutes)

• After the group is done adjusting the issue, they can submit it. Help them if that is needed. (20 minutes)

Final discussion and wrap up

• Give prizes/acknowledgement to the group that had the best feedback!(10 minutes)

Before the events:

Check all the details of this activity here.

Discover the skills of your participants:

• If you don’t know the skills of your participants, you can ask them to fill out a survey about it, That would make selecting appropriate bugs and dividing the participants into group easier

• Skills you can ask about: HTML, CSS, and JavaScript are the most common skills, but there are also others, e.g. HTTP, SVG, or WebAssembly.

• Based on the doodle choose questions you would like your participants to answer. You can either choose
  • General questions about web development.
  • Specific questions asking for help or assessment with the skill tests and assessments that appear on the “Learn web development” section on MDN. If you choose this option, identify which article/task is being assessed, and find the associated marking guide for it.

• Find a good answered question to use an example. We suggest using this one, or this one if you are focusing on general development questions. If you are focusing on Skill tests and assessments this is a great example.

During the event (ca. 1:30 hours)

Introduction on MDN

• Give a general presentation on MDN — Feel free to use this presentation (5 minutes)

• Talk about the different kinds of contributions that people can make (5 minutes)

• Ask people to sign up for Mozilla Discourse (5 minutes)

Introduction on how to help beginners on MDN (30 minutes)

• Show the example question and answer. Explain why it is a good answer.
  • Remember that a  good answer is not only technically correct, but is also respectful and clear and, where appropriate, will help the person to explore the subject further on their own.
  • If you are working on a skill assessment your participants should not only assess if the exercise is done correctly, but try to expand on what was done well and what could be improved.

• Briefly advise people that all questions and answers should respect the Mozilla CPG.

• Divide people in groups based on skills (use the doodle, and ask people that have not complete it to join groups based on their skills)

Answer questions (30 minutes)

• Assign questions to the groups

• Circulate between the groups and help out when needed

• When a group has an answer, help them submit it

Close the event

• After everyone has finished, discuss one of the answers given. (5  minutes)

• Give prizes/acknowledgement to the group that you think gave the best answer (5 minutes)