add drafts/outlines of additional git guideline entries

entries/git-workflow-guidelines/branches.md

@@ -0,0 +1,60 @@
+---
+title: "Branching"
+date: last-modified
+---
+
+{{< include /includes/_wip.qmd >}}
+
+- When to branch? How much should one branch cover?
+
+### Branch Naming
+
+When you create a branch, remember to give the branch a short, descriptive name to clearly communicate to your collaborators what this work is on. We encourage the use of prefixes so anyone can easily identify what kind of work is being done on a certain branch. In addition, we encourage using a forward slah (/) after the prefix. The use of the slash results in the name being interpreted by many IDEs and git tools as a directory structure, which creates a nice grouping of the branches. For prefixes and examples, see the table below.
+
+| Type | Usecase | Pattern | Example |
+|-|---|---|---|
+| Bugfix | for fixing a bug | bug/(short-description) | bug/pen-test-finding |
+| Feature | for adding, removing, or modifying a feature* | feature/(short-description) | feature/update-default-table |
+| Hotfix | for quickly fixing critical issues, usually with a temporary solution | hotfix/(short-description) | hotfix/fix-select-button |
+
+In which (short-description) is a short phrase, such as recursive-loop-fix or init-git-entry, concisely describing the work done on the branch.
+*a feature can also be adding or modifying documentation.
+
+Inspired by [this post](https://code.erpenbeck.io/git/2021/03/01/git-naming-conventions/) and [this post](https://gist.github.com/digitaljhelms/4287848).
+
+- Which also included these:
+  - | User | user/(user-id)/(short-description) | user/merpenbeck/sandbox |
+  - | Topic | topic/(id)-(short-description) | topic/456-query-optimization |
+  - | Release | release/(release-id) | release/2021-04-13 |
+  - | Support | support/(id)-(short-description) | support/876-app-support-reboot-fix |
+  - | Bugfix (alternative) | bugfix/(id)-(short-description) | bugfix/689-pen-test-finding |
+
+Expanding on the use cases of each type of branch:
+
+- Bugfix: Created when there is a bug on the main branch that should be fixed and merged into the next deployment.
+- Feature: For the development of a new feature or enhancement which has the potential of a development lifespan longer than a single deployment.
+- Hotfix: Comes from the need to act immediately upon an undesired state of a live production version.
+
+As with file naming, we use kebab-case. (not written anywhere why we do it or that we do it?)
+
+MORE:
+
+- 3. Use the ID of the Issue
+  - Using the ID of the related issue in the branch name makes it easy to identify the task and keep track of its progress.
+  - Example: wip-451-optimize-data-analysis
+
+  - This name indicates that the task of optimizing data analysis related to issue 451 is a work in progress.
+
+- 4. Include Author Name
+  - Another approach is to also include the name of the author working on the branch, to keep track of developers' work. Usually, the name of the author is the first element of the branch name, according to this format: author-category-name.
+
+  - Example: jane.doe-bugfix-broken-link
+
+- Summary
+  - Keep it short and concise, but make sure to include relevant key words.
+  - Use category words to easily identify the type of the task.
+  - Include ID of related issues to help tracking of progress.
+  - Adding the name of the author helps to keep track of shared work.
+  - Keep the same name conventions for the whole project.
+
+From: <https://tilburgsciencehub.com/building-blocks/collaborate-and-share-your-work/use-github/naming-git-branches/>

entries/git-workflow-guidelines/commits.md

@@ -0,0 +1,29 @@
+---
+title: "Commits"
+date: last-modified
+---
+
+{{< include /includes/_wip.qmd >}}
+
+- Atomic commits
+- Commit messages
+- Referring to issues
+
+## Commit guidelines
+
+GitHub Flow docs (<https://docs.github.com/en/get-started/quickstart/github-flow>):
+
+- Commit and push your changes to your branch. Give each commit a descriptive message to help you and future contributors understand what changes the commit contains. For example, fix typo or increase rate limit.
+- Ideally, each commit contains an isolated, complete change. This makes it easy to revert your changes if you decide to take a different approach. For example, if you want to rename a variable and add some tests, put the variable rename in one commit and the tests in another commit. Later, if you want to keep the tests but revert the variable rename, you can revert the specific commit that contained the variable rename. If you put the variable rename and tests in the same commit or spread the variable rename across multiple commits, you would spend more effort reverting your changes.
+
+By committing and pushing your changes, you back up your work to remote storage. This means that you can access your work from any device. It also means that your collaborators can see your work, answer questions, and make suggestions or contributions.
+
+Continue to make, commit, and push changes to your branch until you are ready to ask for feedback.
+
+- Atomic git commits:
+  - Working with atomic git commits means your commits are of the smallest possible size. Each commit does one, and only one simple thing, that can be summed up in a simple sentence. The amount of code change doesn't matter.
+- Commit messages
+  - best practices
+  - prefixes: fix, feat, style, refactor, test, etc.
+  - reference issues
+  - other?

entries/git-workflow-guidelines/issues.md

@@ -0,0 +1,19 @@
+---
+title: "Issues"
+date: last-modified
+---
+
+{{< include /includes/_wip.qmd >}}
+
+- When to create issues
+- Issue naming
+- Richard’s point on writing from a user/reader’s POV
+- Issue templates. Which kinds of issues do we expect?
+  - Documentation Clarification
+  - Feature Request
+  - Bug Report
+  - Report a Safety Vulnerability
+    - <https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/about-issue-and-pull-request-templates>
+    - <https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository>
+
+Maybe: GitHub Action for issues: E.g., label, assign (maybe to someone per default?), is the issue reproducable?

entries/git-workflow-guidelines/prs.md

@@ -0,0 +1,53 @@
+---
+title: "Pull Requests"
+date: last-modified
+---
+
+{{< include /includes/_wip.qmd >}}
+
+## Pull Request Naming
+
+Pull requests (PRs) are proposed changes from one branch to another. However, they are more than just changes; they are the start of a discussion
+
+- You don't want to work in a silo; you are not going to enrich your own software development learning, if you are working by yourself - you are not getting any feedback and learn from your collaborators experience, if you haven't talked to them.
+
+- And that talking, that collaboration, is so important.
+
+A PR starts with a branch, then you work on that branch and implement the changes you want (push them to GitHub), and then you propose those changes back to the main branch in a PR.
+
+**PR title: Concise; compare to an email subject line; I want to be able to look at the subject line and know what's going to be in the email**
+**Comment: Remember to comment.**
+
+PRs also works as documentation, since they are up there forever
+
+- when a new developer comes in, sees this piece of code change, and want to know the motivation behind the change, you have a URL you can send to them "here's the conversation that we had, where's why" - and if they want to comment on that change, they should comment on that PR
+
+How to use PRs well?
+
+- The shorter the changes, the faster it will be reviewed
+  - Also: Create your PRs early (don't wait until your feature is complete bc then someone else might start working on it) - and then you will have something to talk about
+  - Change something to talk about and then send the PR
+- CI pipeline; tests run automatically - in the PR (so they will be a part of the story of that feature) - to ensure that your PR is merged with confidence
+
+"Peer Code Reviews are the single biggest thing you can do to improve your code"
+
+- Jeff Atwood
+
+In GitHub repositories, the main branch is protected, which means that an admin (?) at Seedcase needs to review and approve the changes before they can be pushed to the main branch.
+
+Summary
+
+- If you need code review, decide what's best for your team
+  - Culture of communicating on the PRs, ask to review work
+- If you want more code review, use the API or a service like ReviewNinja
+
+- At it's core, GitHub Flow is a lightweight, branch-based workflow that supports teams and projects where deployments are made regularly.
+- Allows us to be flexible with the code review
+
+### How to name and describe PRs?
+
+- PR templates (hurray)
+
+### Review guidelines
+
+For guidelines on how to review a pr, see the post [Review through pull requests](https://seedcase-project.org/community/guide-entries/reviewing-prs/index.html) <- maybe move that info here instead.