All of you are welcome to our community, to use our code, to praise or criticize us, but above all your feedback and involvement will be highly appreciated and for sure it will make you feel good when giving back.
This community’s purpose is
to encourage creativity
in the financial industry, to create an environment where ideas are seeded and brought to ripeness to the benefit of all.
Take for example the payments industry;
the processing of payments has reached a high level of maturity, payments becoming ubiquitous and a commodity in the financial ecosystem.
FinTP is an open source financial transactions processing application meant to be used as an open platform in a strictly regulated market. By achieving a large footprint within its target market, FinTP will push financial transactions interoperability forward – from the current message syntax standard layer towards transactions interpretation – thus attaining a semantic standardization layer.
The rules governing this community are meant to ensure the FinTP release is managed to the benefit of all parties involved, they are not intended to constrain in any way its members’ contributions. We aim to free people’s creativity and brains from reinventing the wheel, as it happens in a closed traditional environment, and allow them to take advantage of all the benefits an open approach brings.
This community is governed by the following set of principles:
Openness. Full and free access to sources and releases.
Inclusion, rather than exclusion. Everybody is welcome to share and contribute.
“Upstream first” philosophy. The primary goal is to get the upstream project to adopt most of the modifications brought by the contributors.
Scalability. The product is modular and the development of one feature does not affect the rest of the code.
Freedom of personal choice. Just enjoy whatever you are doing within the community. No strings attached.
Tracking, history and versioning. Every contribution will be acknowledged, the history of your activity under Github will be but within your grasp, all version will be managed through Github built-in mechanism.
Dynamic decision making structure. Equal importance have choosing the best paths and the reaction time, so we try to shorten the chain of command and empower people by voting and keeping the projects as autonomous as possible.
A secure collaborative environment for users and contributors. Heads-up: No, we do not hold sensitive financial data!
Clear and transparent governance is a key part of any open development project. It defines the rules of engagement within the community and describes what level of influence a community member can expect to have over a project. In addition, it enables members to decide their level of involvement with that community.
The community encourages loyalty rather than legalities. Members are free to take the code and create alternative projects as long as this is for the benefit of the community, rather than for a single individual or company.
As you may see in Voting section, not everyone has a binding vote. This happens in order to give the decision making authority to those who share a common vision and, just as importantly, are willing to work towards that shared vision.
Anyone who has an interest in the community may become a member. Actually, there is no community if it does not have purpose and this is given by its members.
Users who continue to engage with the project and its community will often become more and more involved. Such users may find themselves becoming contributors.
Community members who wish to take part in concrete ways in the community running may become a contributor, and contributions can take many forms. All contributions are to be submitted as patches that should be validated by committers or project maintainers.
Contributors engage with the project through forum, blog, Idea box, projects, and mailing lists. There is no expectation of commitment to the project, no specific skill requirements and no selection process.
Contributors can be nominated as committers as soon as they proved their attachment to the community projects and willingness to help in reaching their goals.
Committers are community members who have shown that they are dedicated to the continuous development of the projects through ongoing engagement with the community. Committership allows contributors to more easily carry on with their project related activities by giving them direct access to the project’s resources. That is, they can make changes directly to project outputs, without having to submit changes via patches.
Anyone can become a committer; there are no special requirements, other than to have shown a willingness and ability to participate in the project as a team player.
Nominees may decline their appointment as a committer. However, this is unusual, as the project does not expect any specific time or resource commitment from its community members. The intention behind the role of committer is to allow people to contribute to the project more easily, not to tie them in to the project in any formal way.
It is important to recognize that committership is a privilege, not a right. That privilege must be earned and once earned it can be removed by the Technical Committee in extreme circumstances. However, under normal circumstances committership exists for as long as the committer wishes to continue engaging with the project.
A committer who shows an above-average level of contribution to the project, particularly with respect to its strategic direction and long-term health, may be nominated to become project maintainer, and thus part of the Technical Committee.
The technical committee consists of all project maintainers. Its main role is to set a vision and strategy for the community, as a whole, especially from the technical and business point of view, to decide upon matters that cannot reach a consensus among the members of the community. Its members are expected to review code contributions, participate in strategic planning, approve changes to the governance model and manage the copyrights within the project outputs.
Members of the technical committee do not have significant authority over other members of the community, although they are to vote on new committers. They have access to the project’s private mailing list and its archives. This list is used for sensitive issues, such as votes for new committers and legal matters that cannot be discussed in public. It is never used for project management or planning.
The technical committee leader is voted for by its memners. Once someone has been appointed leader, he/ she remains in that role until choosing to retire, is removed by a majority vote. He/ she has no additional authority over other members of the technical committee: the role is one of coordinator and facilitator, but also to ensure that all governance processes are adhered to.
This is a group of decision makers with the role of a moderator: the instrumental inspirational authority, expected to draw both the development vision and the guidelines of the community.
All participants in the community are encouraged to provide support for new users within the project management infrastructure. This support is provided as a way of growing the community. Those seeking support should recognize that all support activity within the project is voluntary and is therefore provided as and when time allows. A user requiring guaranteed response times or results should therefore seek to purchase a support contract from a community member. However, for those willing to engage with the project on its own terms, and willing to help support other users, the community support channels are ideal.
4. Contribution Process
Anyone can contribute to the project, regardless of their skills, as there are many ways to contribute. For more details, please visit section How to Contribute and Structure and Roles.
5. Decision Making Process
Decisions about the future of the project are made through discussion with all members of the community, from the newest user to the most experienced member. Most of these discussions will take place in public spaces (such as forums). It may happen that some sensitive discussions will occur on a private area (such as private mailing list).
In order to ensure that the project is not bogged down by endless discussion and continual voting, the project operates a policy of lazy consensus. This allows the majority of decisions to be made without resorting to a formal vote.
Decision making typically involves the following steps:
Vote (if consensus is not reached through discussion)
Any community member can make a proposal for consideration by the community. In order to initiate a discussion about a new idea, they should post a proposal on available forums (built within fintp.org, https://github.com/FinTP), on the issue tracker. This will prompt a review and, if necessary, a discussion of the idea. The goal of this review and discussion is to gain approval for the contribution. Since most people in the project community have a shared vision, there is often little need for discussion in order to reach consensus.
For more details on how a proposal may reach consensus and be approved, please see Types of approval.
Issues such as those affecting the strategic direction or legal standing of the project must gain explicit approval in the form of a vote. Every member of the community is encouraged to express their opinions in all discussion and all votes. For more details please see section Voting.
Board of Directors
Dan Ion Anghelescu
The website is built over Wordpress and it uses plugins to display content as intended.
Some contents or functionalities here are not available due to your cookie preferences!