Developer Guide Outline/Draft

1. Purpose of this guide - why did we create it
2. Who this guide is for
3. xxxx
4. xxxx
5. xxxx
6. xxxx

DCI WG Wishlist - What diversity, civility and inclusion practices and principles do WE want to see in the Hyperledger community?

• Equal Attention to Pull Requests
  1. Pull requests should receive attention and feedback in order of submission.
     1. Note that the above does not mean that pull requests also have to be merged in order of submission since some of them will take a few minutes to review and approve while other changes might take days or weeks or even months to fully form a consensus on among the maintainers and the submitter.
  2. While merging in order is not required, it is still the polite thing to do for pull requests that received approval at (roughly) the same time, unless there's a specific technical reason for not doing so. The reason for this is to put the burden of rebasing one's code to another's to the person who submitted their pull request at a later time which is considered fairer than the other way around because the first pull request's author could not have known about the change made by the second pull request at the time of conception of their (first) pull request.
     1. The resulting additional merge conflicts would be significant if the order of pull requests merged were to be changed
     2. Urgent hot-fixes, security patches that need to be expedited for obvious reasons
     3. Other legitimate technical/practical reasons where the definition of legitimacy is at the discretion of the maintainers.
  3. Example scenarios to avoid:
     1. Skyler is a well known contributor for a project while Pat is a newcomer who has just opened their very first pull request and they don't know anyone nor does anyone know them from the open source community of the project.
        Pat submits a pull request that has no issues with it and is waiting for a review from the maintainers.
        
        The next day, Skyler submits a pull request and immediately gets an approval from the maintainers.
        A week later Pat also receives approval for their pull request.
        
        Since there was no changes requested in Pat's pull request, there was no reason why it should not have been reviewed (and accepted in this case) first, but Skyler's pull request made it to the top of the queue because of their personal relationships in the community.
        
        
        
     2. Bernie submits a pull request changing a specific component of the code. Cory, a few days later also submits a pull request changing the same component.
        Both of their changes make sense and are acceptable to the maintainers as is. Both of their changes are based off of the main branch and can be merged, but they are in conflict with each other meaning that the pull request that gets merged second will have to do conflict resolution and potentially a small refactoring of the change itself.
        
        The amount of conflict resolution work to be done would be roughly the same for both Bernie and Cory.
        Both pull requests have the same urgency (none of them are hot-fixes or security patches)
        
        In this scenario the recommendation is to merge the pull requests in order of submission because there are no technical/practical factors that would justify merging Cory's pull request out of order (e.g. before Bernie's)
• Open and Welcome Communication on Rocketchat Channels: Similar to the above recommendations around pull requests, we want to provide welcoming and inclusivity when conducting business on the RocketChat channels. We want newcomers to feel welcome and all questions to be answered in a timely manner.
• xxxx