How to contribute
You are welcome to our community, to use our code, praise or criticize us. We rely on your feedback and involvement.
There are many ways you can contribute and thus become part of a living community. The more dedicated you become, the more possibilities will open.
To learn more about these, please see the Structure and Roles section.
Do you have an idea of a feature or new project you think is useful and worth adding? Our forum is open. You can post your proposal and see how things go. Community registered members comment and vote. All ideas are analyzed and stand a good chance of being implemented after approval by the community members.
Contributors can submit patches that can become part of the project outputs. All contributions will be acknowledged and thanked for.
This community started out as a group of people with complementary skills, who work together to achieve freedom in exchanging information and bringing fixes and suggestions to projects.
When the founding members feel that a person has earned the merit to be part of the development community, they grant them direct access to the source code. This way, people are encouraged to submit suggestions or patches or to join the debates hosted on the forum.
Everybody is welcome to join this community and contribute according to his or her area of expertise. The meritocracy system is being updated and implemented as FINkers United expands, depending on the needs of the members and evolution of both the project and community.
Structure and roles
| members – anyone can become member of the community. You need 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
• support 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 to 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 are submitted as patches and validated by committers or project maintainers. Your contributions are always acknowledged. There are several things a member cannot do, but a contributor can, such as:
• analyzing and designing requirements
• adding features
• 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 to 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 possibility of influencing the paths the project is taking. All you have to do is to agree to 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 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. The 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.
Help us out
The FINkers United association is a non-profit organization, currently supported by Allevo.
You can help us by:
1. Redirecting 2% of any income tax paid in Romania to the FINkers United association (applicable if you are not tax exempt). To do this, please fill in the form below and send it to ANAF, using this IBAN: RO34INGB0000999904411859. The money are used for promotion of FINkers United, to drive more adoption and speed up releases of new features.
Please note this is an interactive form. You may not be able to view it in your browser. We suggest you right click, save link as… and open the file locally.
2. Spreading the word – include a link to fintp.org on your website or simply say something nice about it on social media.
3. Giving a testimonial – what you like about FinTP or FINkers United, how it helped you achieve something.
When taking decisions, it is important to make each member’s opinion count. This is how you can actually become part of the decision making process and decide upon the community’s future.
Every community member is expected to share his/her opinion by casting votes. However, only the meritorious members will have a binding vote for the purpose of decision making (project maintainers, committers, Steering Committee members). This does not mean that you cannot make a difference, even if you are none of the above mentioned meritorious members, as a well justified vote may get supported by a binding vote.
A veto can be expressed only by binding votes. Any objection is to be addressed by the community until the objection is either revoked, overruled (in the case of non-binding votes) or the proposal is so altered as to achieve consensus. If no consensus is achieved, then Steering Committee may decide upon it.
You can vote:
• +1 ‘agree and willing to help bring about the proposed action’ – Ok, let’s do it!
• +0 ‘agree’, but not willing or able to help bring about the proposed action’ – Ok, you do it!
• -0 ‘disagree, but will not oppose the action’s going forward’ – No, thanks!
• -1 ‘disagree and opposes the action’s going forward’. It would be helpful to propose an alternative action to address the
issue (or a justification for not addressing the issue) – No way, it should be like this!
We know it might look a bit odd ±0, but trust us, it makes sense when letting us know your thoughts on proposed actions. They actually address those situations when you might not feel very confident of your skills (technical or not).
From here forward you may find these dubbed as follows:
• +1, +0: positive votes
• -0, -1: negative votes
• -1: objection
• -1 binding vote: veto
Types of approval
Lazy consensus: “Good! No objection!”
We encourage all community members to give their supporting arguments when casting a negative vote, so that those entitled to binding votes will have the possibility of evaluating them and support the objections raised, if the case.
Lazy majority: “I should get them on my side!”
This time the community members are to show their appreciation towards your intention, meaning you will have to gain more positive than negative votes and no vetoes. And all these in about 72 hours.
Consensus approval: “At least one more!”
Consensus approval requires the usual 50% of the casted binding votes and one more to be positive. No veto is allowed. You may receive negative simple votes, as long as you also get (50%+1) of the simple votes. And all these in about 72 hours.
Unanimous consensus: “Hmmm, this was hard!”
Unanimous consensus requires that all binding votes that are casted are positive. 120 hours should be enough.
Majority: “Wow! This time I’ve outdone myself!”
Majority requires 2/3 of all the binding voters to cast positive votes. 120 hours should be enough.
When should you vote?
Not all the decisions are to be taken following a formal voting. Furthermore, we aim to allow most of the decisions to be taken through lazy consensus (see above). Below you can find a list of the most common situations when voting is required (just to be sure that all of you had the chance to speak up):
• Release plan. All of you should know and adhere to the timetable and actions for a release (if fast reaction is required, a lazy majority should suffice).
• Product release. By this voting you will acknowledge that the released product within one project became the official release of the project (if fast reaction is required, a lazy majority should suffice).
• New committer/ removal of a committer. It requires consensus approval.
• New member in Steering Committee/ removal of a member of the Steering Committee. It requires majority approval.
When a situation requires, there is a call for voting. Besides the matter itself, the type of vote is announced. Just go to the dedicated section within the forum, access the proposal and check your option of the four available. In order to place your comment, please reply to the post. The result is automatically summarized.