BitBroker is a policy-based, data sharing engine which enables you to securely share:

• The data segments you permit
• In ways which you allow
• With organisations that you approve

It's a complete, end-to-end data sharing solution, allowing you to Share Your Data with Confidence

If you are new to BitBroker, you should head over to our main website at www.bit-broker.io. There you can learn all about the project, what it does, how it works and how to leverage it for your own data sharing use cases. Amongst other things, you will find:

• A full set of interactive demos which show a live working instance of BitBroker
• A clear and simple getting started guide, to help you deploy and operate your own BitBroker instance
• Full system and technical documentation, detailing everything you need to know to leverage BitBroker
• Lots of samples and example so get you started on extracting value from BitBroker

Why not start by playing with the demo instance. Its just a few clicks aways and requires nothing but a browser and a few minutes of your time.

You can get timely updates and news by following us on Twitter.

BitBroker is open source under the generous and permissive Apache 2 license.

The following is a breakdown of the repositories you will find within this GitHub organisation.

You will find more technical documentation is held within the readme structures of the repositories themselves. The getting started guide is the best place to head to in order to get these components up and running in your own deployment space.

If you have issues or questions about BitBroker, we would encourage you first to have a good root around the public documentation. Here you should find the answer to the most frequent questions. We will improve this documentation whenever new questions arise.

If you don't find an answer to your question or issue, then please feel free to open a new issue on this main organisation wide repo. We endeavour to respond to all new issues in a prompt and timely manner. We might move your issue to one of the sub-repos if it more appropriately belongs there.

If you have a specific issue with one component which makes up BitBroker, then you should open an issue on that repository directly. But, please do search through the existing open issue first in order to minimise duplication and potentially save yourself time. If you find an open issue already, do add a note to it explaining your perspective and experiences.

TODO - Should we introduce a better question channel like slack, teams or even email?

We welcome contributions from people on any or all of the repositories which make up the system.

The current BitBroker core team is:

Together this group forms the leadership of the BitBroker project. All key project decisions will be made by this group, which will meet on a regular basis. Please feel free to lobby any one of them in order to voice issues which you want addressed. Remember, the best approach is to first create an issue using the appropriate issue tracking mechanism listed earlier in this document.

All the decisions made by the leadership group will be documented clearly either in the project documentation or in response to specific issues raised in the issue tracking area.

Given the early stage of the project, the project will operate in a de-facto "Benevolent Dictator" model, where the "dictator" is the small core BitBroker team outlined earlier in this document. This team has the final say on all major project decisions. Contributors who have issues, requests or suggestions are encouraged to contact any member of this team, who will then bring it to the attention of the others. The team commit to meet on a regular basis and to publish all their decisions in an open and transparent way.

The core team is committed to moving to a more community led approach for BitBroker in the future, when the project is more established and its goals and boundaries are better understood and defined.

At this stage, we do not have an extensive formal Code of Conduct document. However we do have some basic requirements which we ask that contributors respect.

The BitBroker team is committed to open and positive communication to promote an environment that ensures that all participants feel welcomed, respected and supported. We recognise that the GitHub community is diverse and that people have different backgrounds, experiences, and understandings of what constitutes offensive or inappropriate behaviour. We ask the all contributors apply common sense rules as to their own behaviour and think carefully about how their actions and communications might be perceived by other people.

The BitBroker team will not tolerate any behaviour which we deem to be offensive or inappropriate.

Examples of such behaviour are (but not limited too): Offensive comments related to personal traits or lifestyle choices and practices, sexual references or unwanted sexual attention, threats, intimidation, disruption, doxing, etc. Ultimately, the team reserves the right to decide what is-and-is-not acceptable behaviour. Reporting

If you witness behaviour which you think is not appropriate, we encourage you to sensitively and respectfully dissuade the originator from such behaviour. If such behaviour continues, or is of a very serious nature, you should contact the BitBroker leadership team.

If you are the victim of behaviour which you feel is inappropriate or offensive, you should contact the BitBroker leadership team. We promise to listen, to care and to help resolve the matter in the quickest way possible and in a manner which preserves your confidentiality.

Participants asked to stop any unacceptable behaviour are expected to comply immediately. If a participant continues violates this policy, the BitBroker team reserves the right to remove them from the project and rescind all the rights they have within GitHub and within all associated communication channels.

This procedure applies to the following repositories:

• bit-broker
• examples
• charts
• website

These two ancillary repositories, will follow a separate path (see below for details):

• auth-service
• rate-service

BitBroker version and release methodology will follow the semver process. Here, the version number MAJOR.MINOR.PATCH increments as follows:

1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards compatible manner, and
3. PATCH version when you make backwards compatible bug fixes and improvements.

On accepting a component Pull Request which requires a version update per the criteria above, the Core Team will decide when to create the appropriate tag. They will make a decision based upon their wide knowledge of the current state of the repository and understanding of the state of up-coming and / or pending changes.

Once tagged, this will trigger the automatic creation of component docker images, with corresponding version tags. Announcements of new tags, will be made here and on our Twitter account.

We endeavor to keep the previous version of BitBroker operational and in good-order, wherever possible. We may, for example, create branches from previous version tags, in order to apply minor fixes or improvements. Decisions on this will be made by the Core Team and announcements made here.

As the coordinator, contributor and consumer services are in a common repository, they will share the same version numbers. This is true even when changes have been made that only affect one of the services.

Incompatible REST API changes will require a new REST API version in the API URLs. As the coordinator, contributor and consumer services implement the BitBroker REST API, the major version of these components to track the REST API version.

We are using flyway to handle database schema versioning and migration. We will manage schema versioning independently of component versioning. All database schema changes will require a tested database migration script.

The auth-service and rate-service are ancillary services. These are used-by, but not strictly part-of BitBroker. Hence these two components will follow their own release process. However, they will still follow the same semver methodology outlined above.

Changes to these services will be announced here and on our Twitter account.