Structure and Roles

Here are some insights of the community structure. Its aim is to give you a hint where you could best fit and how to optimize your activity within the community.

1. Contributors:

  • members – anyone can become member of the community. You just have to be interested in what we are doing. You might very well be a user who downloaded and used our code and now just feel the need to give us your feedback, either to praise or to criticize. You might want to stay in touch with forum discussions, latest news and events or just burst with new ideas and suggestions. When becoming a member you will be asked to agree to our code of conduct. We would very much appreciate if you
  • tell your friends and peers about us
  • provide feedback on your experience using our outcomes, we even accept  bugs
  • inform our developers of strengths and weaknesses you found and
    identify possible new features
  • supporting new users (share the experience you gained)
  • provide moral support
  • individual contributors – once a member of the community, you may become a contributor. You  just need o be willing to give away the outcomes of your activity within the community, no matter if you are a requirements designer, architect, developer, tester, document writer, or translator. Your artifacts will be submitted as patches and validated by committers or project maintainers. Your contributions will always be acknowledged. There are several things a member cannot do, but a contributor can, such as:
      • analyzing and designing requirements
      • adding features
      • programming
      • fixing bugs
      • writing documentation
      • software localization
      • providing graphics and web design

There is no actual selection process; all you have to do is to agree upon the terms and conditions of the CLA (Contribution License Agreement).

  • corporate contributors – if you are a company willing to empower your employees to become contributors within our community, then this is your corner. This way you will always be in the middle of things, and also you will have the possiblity of influencing the paths the project are going. All you have to do is to agree the terms and conditions of the CCLA (Corporate Contribution License Agreement) in order to avoid any copyright issues that may rise. This will come together with a list of your employees you agree to become contributors.
  • committers – as contributors gain experience and familiarity with the project, their profile  within (and commitment to) the community will increase. Generally, a potential committer is a contributor who has shown an understanding of the project, its objectives and its strategy and has provided valuable contributions to the project over a period of time. Consequently, the community will return his/her trust and he/she may be nominated for committership by an already existing committers (initially, these are the project maintainers). Committers have no more authority over the project than contributors, as their work continues to be reviewed by the community before acceptance in an official release. The key difference between a committer and a contributor is when this approval is sought from the community: a committer seeks approval after the contribution is made, rather than before. Seeking approval after making a contribution is known as a commit-then-review process. It is more efficient to allow trusted people to  make direct contributions, as the majority of those contributions will be accepted by the project. The candidates for committership are voted within the project. Once the vote has been held, the aggregated voting results are published. The nominee is entitled to request an explanation of any ‘no’ votes against him/her, regardless of the outcome of the vote. This explanation will be provided by the project maintainer and will be anonymous and constructive in nature. Nominees may decline their appointment as a committer. However, this is unusual.

2. Project maintainers – contributors with leading role in managing the project assigned. His/her role is to ensure the smooth running of the project by reviewing code contributions, participating  in strategic planning, deciding upon matters for which the consensus cannot be reached, making sure that all governance processes are adhered to. The project maintainer has access to the project’s private sections and its archives (used for sensitive issues, such as votes for new committers and legal matters that cannot be discussed in public). The project maintainer is nominated by the existing project maintainers and is voted together with the project members. Technical committee may cast a veto. The project maintainer remains in that role until he/she retires or the majority vote removes him/her.

3. Technical committee – includes all the project maintainers. They are entitled to cast binding votes, can nominate committers and have a representative within the Steering Committee of the community. They may approve changes to the governance model and manage the copyrights within the project outputs and decide on matters that affect more projects.

4. Steering committee – a group of decision makers which has the role of the moderator: the instrumental inspirational authority, expected to draw both the development vision and the guidelines of the community.

We use cookies to deliver a cosy experience on our website.

 

The website is built over Wordpress and it uses plugins to display content as intended.

 

By accepting this notice, you consent to cookies on this device as per our Cookie Policy.

Some contents or functionalities here are not available due to your cookie preferences!

This happens because the functionality/content marked as “%SERVICE_NAME%” uses cookies that you choosed to keep disabled. In order to view this content or use this functionality, please enable cookies: click here to open your cookie preferences.