👥 Section incorporating community research and development

[JFWooten4]

Solves JFWooten4/DUNA-docs#3

Before we conclude, I suggest adding a section that reinforces the initial work showcased and includes stories of intermediation failure. It seems important to inspire the Commission with hope and faith that something better and new exists. We can indeed offer infrastructure to parallel today’s dangers, markedly upgrading the experience of DRS investors. 📈

[JFWooten4]

The "intermediation failure" part can be laid out without explicit DTCC reference through the other institutions. Will just need to lightly implicate that this is all based on the links commonly underlying the whole framework.

cc @JFWooten4

[JFWooten4]

You can always assign a bunch of people, but I'm sort of aligned with Chive's approach of open access and just letting people do it, which shows up on the co-authorship log. Thus, we don't have (i) central hierarchies or "planning" members bossing others around, or (ii) partial work recognition where the number of assignees is less than the number of branch contributors.

[tehchives]

Just wanted to ask a clarifying question about how Git works - I will ask a few other folks to take a look, but how does Git handle mutiple people putting (potentially conflicting) PRs in at the same time?

[JFWooten4]

At a high level, it will show you both contributors' work, and then you have some options:

• Accepting version A
• Accepting version B
• Merging them manually

All modern code editors¹ have interfaces to help you with all three options. They generally have one-click "Accept this version" buttons while the changes or conflicts are side-by-side. As for the last option, you can always jump in, and it makes it clear which changes are from which branch. Then you just manually keep what you want and remove the rest.

Make sense?

Footnotes

1. Including github.dev cloud VS Code environment ↩

[tehchives]

Yes, thanks!