Update Best Practices and Contribution Guide for LFDT

Update Best Practices and Contribution Guide for LFDT.

Signed-off-by: David Enyeart <[email protected]>

guidelines/github-contribution-guide.md

@@ -8,16 +8,16 @@ grand_parent: LF Decentralized Trust TAC
 
 # GitHub Contribution Guide
 
-This document provides instructions to fork a Hyperledger repository and submit code contributions through a pull request.
-Although there are many GitHub guides available, this guide covers the full set of contribution steps using generally accepted Hyperledger practices.
+This document provides instructions to fork a LF Decentralized Trust (LFDT) repository and submit code contributions through a pull request.
+Although there are many GitHub guides available, this guide covers the full set of contribution steps using generally accepted LFDT practices.
 
 For additional Git/GitHub questions and discussions after reading this guide, reach out on the [git-help Discord channel](https://discord.com/channels/905194001349627914/1098621099681513492).
 
 ## Forking the repository
 
-In order to contribute code to a Hyperledger project, it is required to fork the relevant GitHub repository and submit a pull request from your fork.
+In order to contribute code to a LFDT project, it is required to fork the relevant GitHub repository and submit a pull request from your fork.
 The act of forking a GitHub repository creates an identical copy of the repository in your personal GitHub account.
-You are then able to edit code and propose these changes to the official Hyperledger repository you forked the code from via the GitHub pull request process.
+You are then able to edit code and propose these changes to the official LFDT repository you forked the code from via the GitHub pull request process.
 
 To fork a repository:
 
@@ -48,11 +48,11 @@ To clone a repository:
 git clone [email protected]:<your_github_id>/<repository_name>.git
 ```
 
-- Now change to the repository directory and add a remote upstream repository pointing to the official Hyperledger repository
+- Now change to the repository directory and add a remote upstream repository pointing to the official LFDT repository
 
 ```
 cd <repository_name>
-git remote add upstream https://github.com/hyperledger/<repository_name>.git
+git remote add upstream https://github.com/LF-Decentralized-Trust/<repository_name>.git
 ```
 
 - You can now list your remote branches and confirm your local repository has created a link with the remote upstream repository
@@ -146,18 +146,18 @@ To integrate these changes you must now go through the pull request process.
 ## Opening a Pull Request in GitHub
 
 Now that you've created and pushed changes to a feature branch in your forked repository,
-you can now open a pull request against the original Hyperledger repository from which you created your fork and begin the code review process.
+you can now open a pull request against the original LFDT repository from which you created your fork and begin the code review process.
 
-- Navigate to https://github.com/hyperledger/<original_repository>
+- Navigate to https://github.com/LF-Decentralized-Trust/<original_repository>
 - Select the Pull Request tab at the top of the page
 - In the top right corner of the Pull Requests page, select New Pull Request
 - On the Compare Changes page, select "compare across forks" at the top of the page
-- Select the Hyperledger repository and branch that you want to merge into as the "base repository" and "base" branch
+- Select the LFDT repository and branch that you want to merge into as the "base repository" and "base" branch
 - Select your fork and your feature branch as the "head repository" and "compare" branch
 - Select Create Pull Request
 - You'll have the option to open your pull request as a Draft if you are not yet ready to have it reviewed.
 
-Congratulations, you have now submitted your first pull request to a Hyperledger project.
+Congratulations, you have now submitted your first pull request to a LFDT project.
 Your pull request will now run through CI checks.
 You can monitor your pull request CI progress by navigating to the Checks tab of the pull request.
 If there are CI check failures the pull request may not get reviewed and merged.

guidelines/project-best-practices.md

@@ -11,10 +11,10 @@ nav_order: 4
 
 ## Introduction
 
-This document provides a high level survey of best practices and suggestions for various aspects of management and maintenance of Hyperledger projects.
-In many cases links are provided to other resources at Hyperledger and beyond for more detailed information.
+This document provides a high level survey of best practices and suggestions for various aspects of management and maintenance of LF Decentralized Trust (LFDT) projects.
+In many cases links are provided to other resources at LFDT and beyond for more detailed information.
 
-The best practices generally apply to Hyperledger Graduated projects.
+The best practices generally apply to LFDT Graduated projects.
 Many of the best practices also apply to Incubation projects, especially Incubation projects that are on a path to become a Graduated project.
 
 The document will first provide a survey of existing guidelines and practices and then dive deeper into areas not covered elsewhere.
@@ -72,7 +72,7 @@ The [Project Incubation Exit Criteria](../governing-documents/project-incubation
 
 * Foster a welcoming, positive, and public environment where contributions are encouraged. - See [Creating an Inclusive Community presentation](https://www.youtube.com/watch?v=lHOINFlb9JA)
 * Decisions should be made in public, or at least socialized in public
-* Engage on Discord Chat - see [Suggested Channel Organization and Naming](https://wiki.hyperledger.org/display/TF/Hyperledger%27s+Transition+to+Discord+Proposal)
+* Engage on Discord Chat - see [Suggested Channel Organization and Naming](https://wiki.hyperledger.org/display/TF/Transition+to+Discord+Proposal)
 * Use Mailing lists for official business - start with a single mailing list, consider multiple if there becomes a need (users list versus contributors/maintainers list)
 * Host public meetings on a regular cadence. Ask community about best meeting time, consider two meetings to cover different regions, or rotating meeting times (shifted 8 hours or 12 hours).
 
@@ -86,12 +86,12 @@ The [Project Incubation Exit Criteria](../governing-documents/project-incubation
   - https://hyperledger.github.io/firefly/contributors/
   - https://github.com/hyperledger/iroha/blob/main/CONTRIBUTING.rst
 * Present at Meetups - Virtual or in person – these are well attended and the videos also get many views
-  - Email meetup@hyperledger.org if you're interested in presenting or join one of the [bi-weekly Meetup and Workshop planning calls every other Thursday at 9:30 AM pacific](https://lists.hyperledger.org/g/meetups/calendar)
+  - Email meetup@lfdecentralizedtrust.org if you're interested in presenting or join one of the [bi-weekly Meetup and Workshop planning calls every other Thursday at 9:30 AM pacific](https://lists.lfdecentralizedtrust.org/g/meetups/calendar)
 * Host technical Workshops - Virtual or in person (e.g. Global Forum) – these are well attended and the videos also get many views
-  - Reach out to one of the Hyperledger Community Architects or join one of the [bi-weekly Meetup and Workshop planning calls every other Thursday at 9:30 AM pacific](https://lists.hyperledger.org/g/meetups/calendar)
+  - Reach out to one of the LFDT Community Architects or join one of the [bi-weekly Meetup and Workshop planning calls every other Thursday at 9:30 AM pacific](https://lists.lfdecentralizedtrust.org/g/meetups/calendar)
 * Take part in annual Mentorship program
-  - Near the beginning of each year maintainers have the option to [submit projects to the annual Hyperledger mentorship program](https://wiki.hyperledger.org/display/INTERN/Mentorship+Projects) and work with mentees or code, documentation or research projects
-* See also [Raising the Profile of your Hyperledger Project or Lab](https://docs.google.com/presentation/d/13nji_R-op77ERT-AV3-CbOOZwAOjtvq33RRGnjpL3Gc/edit#slide=id.g3cf4a9ebda_0_647)
+  - Near the beginning of each year maintainers have the option to [submit projects to the annual LFDT mentorship program](https://wiki.hyperledger.org/display/INTERN/Mentorship+Projects) and work with mentees or code, documentation or research projects
+* See also [Raising the Profile of your Project or Lab](https://docs.google.com/presentation/d/13nji_R-op77ERT-AV3-CbOOZwAOjtvq33RRGnjpL3Gc/edit#slide=id.g3cf4a9ebda_0_647)
 
 ## Project management and issues
 
@@ -112,18 +112,18 @@ The [Project Incubation Exit Criteria](../governing-documents/project-incubation
 ## Security
 
 * Provide three named security contacts per project
-* Define security issue reporting process in SECURITY.md with reference to [Hyperledger reporting process](https://wiki.hyperledger.org/display/SEC/Defect+Response)
+* Define security issue reporting process in SECURITY.md with reference to [Security reporting process](https://wiki.hyperledger.org/display/SEC/Defect+Response)
 * Review, respond, and act on reported security vulnerabilities
-* Follow security issue disclosure process - see [Disclosure task force](https://github.com/hyperledger/toc/issues/48)
+* Follow security issue disclosure process - see [Disclosure task force](https://github.com/LF-Decentralized-Trust/tac/issues/48)
 * Leverage automated scans, tooling depends on language but usually includes some combination of:
   - linters
   - Software Composition Analysis dependency scans, e.g. Dependabot, Govulncheck
   - Static Application Security Testing (SAST) aka static analysis scans, e.g. CodeQL, Snyk
 * Pin dependencies and keep dependencies up to date,  e.g. using Dependabot, although be wary of auto-upgrades and lookout for malware.
-* Engage with Hyperledger staff on possibility of [security audits](https://wiki.hyperledger.org/display/SEC/Security+Code+Audits) for Graduated project major releases; address audit results and socialize
+* Engage with LFDT staff on possibility of [security audits](https://wiki.hyperledger.org/display/SEC/Security+Code+Audits) for Graduated project major releases; address audit results and socialize
 * Review [OpenSSF secure developer guide](https://github.com/ossf/wg-best-practices-os-developers/blob/main/docs/Concise-Guide-for-Developing-More-Secure-Software.md) and OpenSSF overview presentation to TAC ([charts](https://wiki.hyperledger.org/download/attachments/80775801/OpenSSF%20Hyperledger%2020230119.pdf?version=1&modificationDate=1674218724000&api=v2), [replay](https://youtu.be/0AFFIDKFNvc))
 * Review and obtain OpenSSF Best Practices Badge - see [criteria](https://bestpractices.coreinfrastructure.org/en/criteria/0)
-* Sign release artifacts (TBD) - see proposed [Security Artifact Signing task force](https://github.com/hyperledger/toc/issues/49)
+* Sign release artifacts (TBD) - see proposed [Security Artifact Signing task force](https://github.com/LF-Decentralized-Trust/tac/issues/49)
 * Also see [2022 security task force](https://wiki.hyperledger.org/display/TF/Task+Force+Recommendations)
 
 ## Documentation
@@ -143,7 +143,7 @@ The [Project Incubation Exit Criteria](../governing-documents/project-incubation
 * Document Long-term support (LTS) release strategy - [Fabric example](https://github.com/hyperledger/fabric-rfcs/blob/main/text/0005-lts-release-strategy.md)
 * Use Github Actions to automate release process, e.g. publish artifacts and release notes upon drafting a GitHub release
 * Use [Reproducible builds](https://reproducible-builds.org/)
-* Sign release commits with [GPG](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits) (-S or --gpg-sign); sign release artifacts - see [Security Artifact Signing task force](https://github.com/hyperledger/toc/issues/49)
+* Sign release commits with [GPG](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits) (-S or --gpg-sign); sign release artifacts - see [Security Artifact Signing task force](https://github.com/LF-Decentralized-Trust/tac/issues/49)
 * Release artifacts
   - binaries attached to GitHub release
   - NPM packages - don't publish on every commit due to NPM limit of 1000 versions
@@ -156,7 +156,7 @@ The [Project Incubation Exit Criteria](../governing-documents/project-incubation
   - Use [filters](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet) to eliminate unnecessary runs, e.g. doc PRs shouldn't require building and testing code.
   - Consider running some jobs on schedule (nightly) rather than on each pull request (e.g. full matrix of platform tests)
   - Inspect Github Actions run results on your own fork prior to opening Pull Request
-  - Contact Hyperledger staff for the possibility of dedicated paid runners
+  - Contact LFDT staff for the possibility of dedicated paid runners
 * Pull request checks
   - DCO - [Developer Certificate of Origin](https://github.com/apps/dco)
   - Unit tests
@@ -165,7 +165,7 @@ The [Project Incubation Exit Criteria](../governing-documents/project-incubation
   - Note - just because a change passes automated checks doesn't mean it is necessarily good, it still requires judicious maintainer review
 * Test coverage reporting - run on-demand or nightly
 * Keep CI clean and green at all times, address failures and flakes
-* See also proposed [Automated Pipelines task force](https://github.com/hyperledger/toc/issues/44)
+* See also proposed [Automated Pipelines task force](https://github.com/LF-Decentralized-Trust/tac/issues/44)
 
 ## GitHub configuration
 
@@ -188,7 +188,7 @@ The [Project Incubation Exit Criteria](../governing-documents/project-incubation
 ## GitHub workflow
 
 * Although there are often multiple paths to achieve an outcome in git and GitHub, there is value in defining a suggested path for contributors, both for the benefit of new GitHub users, and for the sake of project consistency.
-  - See the [Hyperledger GitHub Contribution Guide](github-contribution-guide.md) for detailed guidance on forking, branching, remotes, creating pull requests, updating pull requests, and cherry picking
+  - See the [LFDT GitHub Contribution Guide](github-contribution-guide.md) for detailed guidance on forking, branching, remotes, creating pull requests, updating pull requests, and cherry picking
 * **Rebase merging** is preferred over **Merge commits** and **Squash merging** to keep commit history and PR description clean (assuming contributors squash/amend their own pull requests)
 * Nice to haves (consult the GitHub Best Practices documentation for details)
   - Try to have all the commits signed on your default branch. This is hard to do in practice, but could come in handy later.