From 578320455421c078e3e1c33e956a2f489f2f63d3 Mon Sep 17 00:00:00 2001 From: Richard Darst Date: Thu, 14 Mar 2024 00:20:36 +0200 Subject: [PATCH] Add some summaries --- content/code-review.md | 8 ++++++++ content/forking-workflow.md | 9 +++++++++ 2 files changed, 17 insertions(+) diff --git a/content/code-review.md b/content/code-review.md index f481e85..92b718e 100644 --- a/content/code-review.md +++ b/content/code-review.md @@ -132,3 +132,11 @@ The fact that pull requests are from branch to branch also strongly suggests that it is a good practice to create a new branch for each pull request. Otherwise you could accidentally modify an open pull request by adding new commits to the source branch. + + +## Summary + +- Our process isn't just about code now. It's about discussion and + working together to make the whole process better. +- GitHub discussions and reviewing is quite powerful and can make + small changes easy. diff --git a/content/forking-workflow.md b/content/forking-workflow.md index 5594197..6a4e3fb 100644 --- a/content/forking-workflow.md +++ b/content/forking-workflow.md @@ -198,3 +198,12 @@ After the update my "branch is up to date" with the upstream repository: - If we later wonder why something was done, we have the issue/proposal as reference and can read up on the reasoning behind a code change ::: + + + +## Summary + +- This forking workflow lets you propose changes to repositories for + which *you have no access*. +- This is the way that much modern open-source software works. +- You can now contribute to any project you can view.