Contribution Process
From Symbian Developer Community
This page will give you a brief overview of the different ways to contribute to the Symbian platform, and the process to follow if you wish to contribute. A contribution is defined as an asset wholly owned by the contributor which is donated to the Symbian Foundation under the following terms:
- the terms and conditions of our web site for non-code contributions,
- one of our contribution agreements for code contributions.
Initially this process is focused towards source code based contributions, but will be extended in the future to cover other types of contribution. Any source-code contribution to the Symbian Foundation must be licensed under the terms of the Eclipse Public License (EPL) or a compatible open source license. If you wish to donate source-code that requires a license for commercial use, you should not use this process and instead should contact the appropriate Technology Manager.
If you are thinking of contributing, you should also read the article on Good Community Behaviour to understand the level of professionalism that is expected of contributors and other stakeholders in the contribution process. This process assumes that you have a basic knowledge of how the Symbian Foundation operates and that you know how to get in touch with the right people. If you're not quite at this level yet, you might like to read the article on discussing potential contributions.
Contents |
Before you Contribute
Contributions to the Symbian Foundation platform can range from reporting a bug to incubating an innovative new project. Broadly there are three categories of contribution that can be made to the Symbian Foundation:
- Problems: If you have found a problem with the Symbian platform we encourage you to tell us about it.
- Opportunities: If you you think there is something new or different we could be doing with the platform, we'd love to hear your ideas.
- Solutions: From bug fixes to new inventions, if you are writing new source-code for the Symbian platform, we welcome your contribution.
There will be more ways to contribute to the Symbian Foundation in the future, but today we are focusing on these three key areas. If you're one step ahead of us and want to contribute to the Symbian Foundation in a different way, please contact our Community Manager.
The illustration below will help you to identify what type of contribution you are planing to make, and provides quick links to the most appropriate section of this guide for your specific circumstances. However, before jumping off elsewhere, if you're planning to contribute source code to the Symbian Foundation it's probably worth becoming familiar with some of the fundamentals of contributing code and our contribution agreements.
Telling the community about a problem
If you have found a problem with the Symbian Foundation platform we encourage you to discuss the problem with the community in the appropriate forums. If you have shared your problems and have not found a suitable solution from the community, you should report that problem using the Symbian Foundation bug tracker.
Submitting a defect is simple and open to everyone. If it is your first time submitting a defect to the Symbian Foundation we recommend that you take a few moments to read our handy Defect Handling Guidelines.
Sharing your opportunities
If you've got a great idea or a calculated master plan (preferably not evil) for the Symbian Foundation platform, we'd love to know about it. Typically ideas get better with input and feedback, so please share your ideas with the community and be receptive to any comments.
As always, we like our community to be bought into any idea, plan or strategic change to the platform, so we've set up a whole site dedicated to the mighty idea. If you want to share, grow and potentially realise your idea on our fantastic platform please visit our ideas site. If the community likes your idea, there may be enough support to start a Symbian Innovation Project to realise your plans.
Contributing Source Code
Source code is the life-blood of the Symbian platform, so we love source code contributions. We'd like to give everyone the freedom to check-in source code, but to ensure that the Symbian platform continues to be great for a long time in the future and to make sure we make best use of our valuable community, some checks and balances are required.
Source code solutions can vary dramatically in size and complexity and need to be treated differently depending on their strategic or architectural impact on the platform. We split source code contributions into four levels; all of which have an associated process that must be followed before a contribution can be made:
- Fix: where you want to contribute source code to fix a platform defect
- Enhance: where you want to contribute source code that makes a minor enhancement to existing functionality
- Extend: where you want to contribute source code that represents a major change to existing functionality or an extension to the platform
- Invent: where you want to start a community-based project to create something new and innovative on the Symbian Foundation platform.
As the complexity level of your contribution increases, an additional process step is added, as shown in the illustration above. Each new process-step is a super-set of the previous, so if you are a prolific contributor, you will quickly become familiar with the process. You will notice that some "invent" and "extend" contributions may not follow the full process. This happens if the invention or extension is either not required or is unsuitable to be included in the official Symbian platform release. This is addressed further in the detailed description of these process steps below.
Contribution Fundamentals
If you are considering making a source code contribution, it is useful to make yourself familiar with the structure of the Symbian platform code and the Symbian foundation coding standards. The Symbian platform is arranged into packages of common functionality as defined by the Symbian System Model. Each package has a package owner who ultimately accepts or rejects any code contribution, and a number of committers who can freely check-in source code. If you would like to contribute to a specific package, but are unsure what to contribute, you should check the package backlog for guidance.
It is essential that you have identified which package your contribution belongs to, and it is useful to discuss your contribution with the package owner or a delegated committer to make sure your proposed contribution is aligned with their expectations. The minimum criteria for a contribution can be found on the coding standards and conventions pages, but individual package owners may have additional package-specific or regulatory requirements. If you are having problems identifying the correct package for your contribution, please ask a question in the Architecture Council Forum.
You will be required to contribute your code using the Symbian Foundation Source Configuration Management (SCM) tool Mercurial (Hg), so it is worth taking time to make yourself familiar with this tool and getting set up with the appropriate client application and accounts. The process for getting set up with Mercurial (Hg) is detailed in our handy Mercurial Quick Start guide.
The Symbian source code repositories contain three code lines for each package:
- Master Code Line (MCL): The main code-line for release quality features. Typically only high priority bug-fixes will be contributed directly to an MCL.
- Release Code Line (RCL): A branch to maintain compatibility with earlier versions of a package, when the MCL undergoes a major change.
- Feature Code Line (FCL): A branch for experimental or immature code development before it is ready to be added to the MCL.
Since there are strict quality requirements for the MCL and RCL branches only the package owner and trusted committers can check-in code on these branches. Unless you have fixed a critical defect that directly affects the MCL and RCL code, the majority of source code contributions are made via the package FCL. Once you are ready to contribute your code, please see Contributing Changes with Mercurial for detailed technical instructions.
We encourage developing in the open which involves working closely with the Symbian Foundation community and collaborating with source-code contributions. This improves community and package owner interest in your project and is the best way to get feedback and help. If you build a good rapport with the package owner and establish a good track record of high-quality contributions, the package owner may consider promoting you to a package committer.
Finally, make sure that you have signed the appropriate contribution agreement - without the appropriate agreement in place we will not be able to use your contributed code.
Contributing a Fix
If you have identified and fixed a new defect, please ensure that you follow the instructions provided in the "Telling the community about a problem" section of this page to report the defect before submitting your fix. It is also useful to get the defect assigned to yourself; this shows that you are nominated solution provider and will prevent any other community member duplicating your effort.
There are two ways to contribute a fix:
- You can attach a Mercurial patch containing your fix to the bug report - used for for quick, small fixes
- You can contribute your fix via a package FCL - used for bulkier fixes for which a Mercurial patch is impractical
Technical details of both these mechanisms can be found at Contributing Changes with Mercurial. You should update the status of Bugzilla accordingly to allow the package owner to assess your fix. It is also vital that you track the progress of your fix using Bugzilla in case the package owner has questions or requires changes to be made.
It is always highly beneficial to discuss your contribution with the package owner responsible for the code to which your fix applies. The package owner will be responsible for accepting or (in rare circumstances) rejecting your fix, so understanding their criteria for acceptance is key to a successful contribution.
Contributing an Enhancement
Enhancements are small changes or improvements to existing functionality - sometimes referred to as "Design Bugs". You should discuss any Enhancement with the package owner of the affected package through the forums and mailing-lists to check that your proposed change complies with the necessary criteria for an enhancement. Broadly, these criteria are:
- The contribution represents a small change to existing functionality
- The number of lines affected is relatively small
- An appropriate package already exisits and only one package is affected
- You are the sole author of the contribution and you are happy for Symbian to use it in any way it chooses
If the package owner is happy that your proposed enhancement complies with the above criteria and does not represent a major impact to the platform they will ask you to submit a bug report describing your enhancement. The bug severity should be set to "Enhancement" and you should use the process defined in the Contributing a Fix section of this page to make your contribution.
If your proposed enhancement does not fully comply with the above criteria or the package owner has other concerns, you will be asked to submit your contribution as a platform "Extension". The process for contributing a platform extension is detailed in the Contributing an Extension section of this page.
Contributing an Extension
If you wish to make a significant source code contribution to the Symbian platform, it is likely to be classified as a platform extension. Broadly speaking platform extensions fulfill one or more of the following criteria:
- The contribution represents a major change to existing functionality
- The number of lines affected is significant
- More than one package is affected
- You will need to create a new package for your contribution
As with all contributions, if possible we recommend that you first identify the relevant package for your contribution and discuss your contribution with the community through the forums or mailing lists. If your contribution requires creation of a new package, please raise this in the Architecture Council Forum where you will be given appropriate guidance by the community or Symbian Foundation staff.
For platform extensions you are required to work with the Symbian Foundation Councils. The Symbian Foundation Councils provide strategic and architectural governance of the platform. There are four councils:
You will be required to provide one or more of the following documents to the councils.
Use the diagram below to help understand which documents you are required to submit for your specific platform extension. However, if you are in any doubt, please ask the Community Manager.
After you have made a successful submission to the councils, you can track it on the Proposals pipeline page. Since all proposals are different and vary in complexity, there in no fixed timescale for a decision. However, you will receive an acknowledgment of your proposal and a target timeline for a decision within one week of making your submission. The Councils will aim to accept or reject your proposal within the target timeline.
If the councils accept your proposal they will ask you to submit a bug report describing your extension. The bug severity should be set to "Feature" and you should use the process defined in the Contributing a Fix section of this page to make your contribution. For Platform extensions it is not appropriate to create a patch to the Master Code Line, so all contributions should be made on a Feature Code Line and merged in to the Master Code Line when appropriate by the package owner.
Don't get too hung-up if the councils reject your proposal. They will provide as much feedback as practical to allow you to decide how to proceed with your contribution and if appropriate you can resubmit an amended proposal. Alternatively you can contribute a Symbian Foundation Platform Accessory which is an optional platform component that does not require council approval. If you choose to contribute a Platform Accessory it is recommended to establish an incubation project to manage the support and maintenance of your Platform Accessory.
Symbian Innovation Projects
If you want to start a new and innovative project from scratch with the Symbian Foundation open source community you can create Symbian Innovation Project using the simple steps described below:
Ideation
If you have a pre-qualified idea, please contact our Community Manager directly to discuss creating a Symbian Innovation Project for your idea. Examples of a qualified idea include a university thesis, a project approved by another Open Source community or a grant funded project.
If your idea is unqualified (i.e. it is a speculative opportunity) we need the Symbian Foundation community to broadly support your idea before you can start your Symbian Innovation Project. The Symbian Ideas site will help you through this process in three steps:
- Presenting your idea to the Symbian Foundation community, generating community support and expert support.
- Finding a lead innovator to take overall responsibility of the Symbian Innovation Project (often the idea owner)
- Helping you to plan your Symbian Innovation Project
If your idea has majority support from the community, at least one expert approval and a willing innovator to lead the project, your idea can move into the incubation phase where it can be developed.
Incubation
Upon entering incubation you will be provided with:
- A project Wiki
- A project Forum
- A project mailing list
- A package-independent FCL
- A community mentor (if required)
- Symbian Foundation Intellectual Property (IP) guidelines
You will have a period of one month to establish your project and publish your charter, plans and team information to your project Wiki. If these are not in place after one month the Community Manager will contact you to make sure you still plan to start the project. If they do not get a response or the project Wiki has not been updated to include these items after one further month, the project will be terminated.
Once a project is past this first hurdle, it will be reviewed on an annual basis. If a project becomes dormant the Community Manager will notify the project team that it has been nominated for termination. The team has 90-days to re-activate the project before it is terminated.
Outside of these two reviews, projects have a free rein to innovate without interference from the Symbian Foundation. We don't impose any additional process until your creation is ready to graduate from the incubation process.
Graduation
It is the responsibility of each project team to prepare their project for "graduation" from the incubator. There are two graduation paths:
- Contributing an Extension: where your project becomes an integral part of the Symbian Foundation platform.
- Platform Accessory: where your project becomes an optional extension for Symbian Foundation platform adopters.
The route that you take will depend on the objective of your project. Typically, if you are providing a well-recognised horizontally integrated extension or industry standard (i.e. a new platform service) it should become part of the platform. If your project focuses on a specific vertical extension of the platform (i.e. a service relating to a specific industrial application) you should consider offering it as a Platform Accessory.
In order to graduate your project as a platform extension, you should follow the instructions on the Contributing an Extension section of this page. Your incubation project will be terminated once your contribution has been approved by the Councils.
If you wish to graduate your project as a Platform Accessory, please contact the Community Manager to arrange for your contribution to be published in the Symbian Foundation Accessory Catalogue. Details about this catalogue and the criteria for inclusion can be found on the Platform Accessory wiki page. Since the Symbian Foundation are not responsible for support and evolution of a Platform Accessory, you may choose to retain your incubator project upon graduation to allow your project team to fulfill this role.
Tracking and Troubleshooting
How can I track the progress of my contribution?
Once your contribution has been made available to the package owner for consideration, you can track it by observing the state of the Bugzilla report that describes it, and also any notes attached to the report. To help with this, by default Bugzilla is configured to send you an email when a report changes state or has content added, if you're the original reporter or the assigned fixer. If you want to track a report where you are not in one of those roles, then you can add yourself to the CC list. Once you're tracking a few contributions, you might want to consider setting up some email filters to help manage the notifications.
What can I do if my contribution is rejected?
There are many possible reasons for a contribution being declined, but the good news is that many of them are quite simple to resolve. The worst thing to do is just try again with exactly the same contribution. Firstly, find out why the the contribution was declined. The reason should be explained in the Bugzilla report that headlines the change. Look for a note attached by the Package Owner (or by one of their appointed Committers). Ideally, the note will also explain how to change the contribution so that it can be accepted. If you can do what's asked, then send in your contribution again. If things get complicated, and Bugzilla becomes too cumbersome, then you could contact the Package Owner directly.
I'm frustrated and want to speak to a real person
Sometimes things just don't go your way and you need a helping hand. If you've exhausted the forums, mailing lists, package owners and wiki and still can't find the help you need, you can contact the following people:
- Symbian Foundation Community Managers
- Symbian Foundation Technology Managers
Process Promise
As an open source foundation, we are not fans of heavyweight processes or making our community jump through unnecessary hoops to make fantastic contributions. However, we do need to ensure that contributions are aligned with the strategy and architecture of the platform, so a tiny amount of paper-pushing is necessary from time to time.
Where we do require our community to work with a process, we aim to ensure that:
- It is open to everyone
- It is easy and intuitive
- It encourages innovation
- It is quick and predictable
If you think that this contribution process is failing in any of these areas, please get in touch.
Comments
Sign in to comment…
