Jump to Navigation

Contribution Guidelines

Introduction

We want to see people contributing to the MeeGo project, and there are many ways to do so. As with any open source project, providing concrete contributions will demonstrate to the project leaders that you are serious about being involved, which helps us separate the people who talk about contributing from the people who actually contribute to the project in a meaningful way. This builds trust in your work, and the people who consistently contribute good work will be given more and more responsibility.

Contributing Code

Because every open source project has slightly different policies for accepting code contributions, here are some specific guidelines for contributing code to MeeGo.

Code contributions should come in the form of patches to MeeGo. This document provides guidance to help people successfully contribute patches that can be accepted by the MeeGo project.

For general information about packaging and what to include in your patch, you should start with the Packaging Guidelines documentation. You should also consider the MeeGo release schedules, including code freeze dates, before submitting your contributions.

Upstream

First, remember that MeeGo makes heavy use of upstream projects, with a focus on contributing code back to the upstream project.

If your patch is related to an upstream project, you will need to develop your code with that upstream project in mind, and then submit it to the upstream project. For most patches, we will wait until they are committed and merged into the upstream project, which allows us to receive all changes in the next release of the upstream project.

For urgent requests, we may make exceptions and include patches that have been accepted and committed in the upstream project, but not yet merged or released.

If you submitted your patch and it was rejected by the upstream project, you should not expect MeeGo to accept your patch.

Submitting Patches to MeeGo

Please send an email to the meego-dev@meego.com mailing list, CC'ing the appropriate project maintainer, with [PATCH] as the first word in the subject line, or attach your patch to a bug report in bugzilla. Please include a description of why you want the change made (not just the "what") and why it is important for MeeGo to make this change. For upstream patches, you should also include a precise description of where the patch is in the upstream project, including a commit ID, if you have it. Your patch will need to include a signed-off-by tag, author's name, and other information. For details about what to include in your patch, you should start with the Packaging Guidelines for Patches documentation.

For kernel patches, configuration changes, and drivers, you should refer to the MeeGo kernel documentation for contributors for additional details about kernel contributions.

Escalation

In a project of this size, patches sometimes slip through the cracks. If you submitted a patch to the meego-dev mailing list or bugzilla and did not receive a response within 5 business days, please send an email to meego-dev and in the first line of that email, include this phrase "Patch escalation: no response for x days". This is one of those rare cases where you should "top post", to make sure that we see the escalation text.

This text is the cue to the project leaders / community managers that we need to make sure someone responds.

Flowchart version of the above process

Code Contribution Flowchart
Credit to timeless for the flowchart.

Other MeeGo Project Contributions

Contributing code is only one way that you can contribute to MeeGo, and we have many other ways for people to contribute to the project. Here are a few examples:

For more ideas about contributing to MeeGo, please see the detailed Contributing to MeeGo Guide on the wiki.