Contribution

Revision as of 10:33, 5 November 2015

How can I contribute?

The Mer project welcomes new contributors! Everybody is invited to help and make a difference. We need more people in every aspect of the project; Documentation, bug fixing, testing and development.

 Every contribution counts.

If you like wikis, writing documentation, working with the community and supporting the non coding efforts part of the Mer project you can make a difference by:

• Wiki gardening: The Wiki is our main source of documentation, and as the project is making quick progress it is a rapidly moving target. Keeping the Wiki up to date to represent the current state of affairs in all aspect of the project is a challenge with extreme importance. Here's an example list of Wiki pages that need to be accurate and one could help by executing them and reporting back any discrepancy or issue they encounter:
  • https://wiki.merproject.org/wiki/Nemo/Installing
  • https://wiki.merproject.org/wiki/Trying_it_out
  • https://wiki.merproject.org/wiki/Platform_SDK
  • https://wiki.merproject.org/wiki/Contribution_in_detail
  • https://wiki.merproject.org/wiki/Building_against_Mer_in_COBS
  • Any other page you use to accomplish something, and you discover is out of date or inaccurate. report a bug against the Wiki component in bugzilla ,once fixed, hope on #mer@freenode to get some review from the community before closing the bug.
• There are also wiki pages used for brainstorming and collaborating, for example [Website Ideas] where you can add your take, suggestions and so forth. Once you've done so hop on #mer@freenode to let the rest of community know if it needs discussion or mail the mailing list for that.
• High level testing: As a user, you are encouraged to use and [end user product] handset vertical and report back issues both to NemoMobile and Mer project, as per the components affected. If in doubt feel always welcome to hop on #nemomobile@freenode and ask around to know whom to contact about an issue.
• You are encouraged as well to test Mer releases and report bugs accordingly. You can find some insight into testing [here].

If you like code, packaging, and are interested in contributing to the project code development take a look here to whet your appetite:

  https://bugs.merproject.org/buglist.cgi?keywords=easyFix&resolution

Issues tagged easyFix are those that should be relatively easy to fix and will get you up and running running with the contribution model and workflow. This usually means proposing a patch to a package, having it reviewed in the [continues integration system] and eventually have it accepted and built onto the package repository.

To get more details about code contributions, read on, as the next sections elaborate just on that.

If you can, and are interested in both, you're more than welcome to contribute to both, as many times, they harmonically coincide.

Contributing to packages

NOTE: If this sections feels a bit brief there's also a page which walks through the change submission process in greater detail..

Our repositories

You can view our repositories at Mer gitlab

Signed-off-by

The Mer project uses the signed-off-by language and process, used by the Linux kernel, to give us a clear chain of trust for every patch received.

Linux Kernel Certificate of Origin v 1.1
"By making a contribution to this project, I certify that:

The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or

The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the
right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license 
(unless I am permitted to submit under a different license), as indicated in the file; or

The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.

I understand and agree that this project and the contribution are public and that a record of the contribution
(including all personal information I submit with it, including my sign-off) is maintained indefinitely
and may be redistributed consistent with this project or the open source license(s) involved."

We have the same requirements for using the signed-off-by process as the Linux kernel has.

In short, you need to include a signed-off-by tag in every patch:

Signed-off-by: this is a developer's certification that he or she has the right to submit the patch for inclusion into the project. It is an agreement to the Developer's Certificate of Origin (above). Code without a proper signoff cannot be merged into the mainline.

Making changes

We use the forking workflow 'Merge Request' approach to accepting changes to packages. This is documented here and the standard feature branch workflow.

When committing, remember to add '-s' option - this adds a Signed-off-by line and is required for Mer contribution and we will not accept patches without.

Responding to reviews

You can help reviewing changes for Mer packages on the Mer Core MR page .