Setup Repositories for BTP Relay / Java BMV / Solidity BMV for BTP Block about btp-product HOT 1 OPEN

Sorry I missed this, let me clarify.

The motivation behind exploring changing the repo structure was that the teams developing BTP 1.1 integrations were doing so in isolation. It was raised that one driving reason for this isolation was the repo structure.

We have addressed this issue of isolation in the ICON Bridge repo. It did not require any changes to the folder structure. In fact, nothing we did was specific to this project. What we did change was the following:

1. Issue tracker is public on GitHub. This way, everyone knows what's going on. We also use Zenhub for project management. The tools themselves are not important. The important thing here is that the issues are publicly shared and that the ongoing development is clear to everyone. Security issues are still private.
2. Issues are triaged and expect a certain level of detail. There are some templates to assist with this.
3. Clear guidelines for development, architecture records, and contributing.
4. A number of static CI checks that come free with open source. These include CodeQL, OpenSSF Scorecards, Codecov, and Dependency Review.
5. Scheduled releases. We found that it is easier to do a release train when multiple teams are collaborating on the same project. Effectively this just means that on the last Monday of every month, we tag a new release. Hotfixes are still adhoc.
6. Trunk based development with branch protection rules. main is the only long-lived branch, and requires submitting a pull request that has 1 reviewer and 1 approver to merge to main. Designated codeowners, PR templates, and PR linting assists with this.
7. Architecture design records and clear documentation for the API, how to build, and how to run tests. This is still being drafted and is going to make its way to the docs folder as .md files pretty soon. Note that the API documentation should just be in the code itself, as described in the development guidelines.

The only changes I anticipate we would make to the folder structure are for the purpose of making provisioning easier, cleaning up unused code, and moving common to its own package. I want to be clear - my entire intent was to get the integration teams on the same page, stop independently working on the same issues, and improve developer effectiveness overall. It ended up having nothing to do with folder structure.

Again, sorry this never got to you. If you are ever left wondering what's going on or have frustrations, please just ping me directly.

from btp-product.