General Guidelines

[sigrunixia]

Continuing the Discussion from Discord, let's figure out what sort of standardization we want to go for. @Obsidian-TTRPG-Community/inquisitors

Here are the Links @scottTomaszewski posted:

• https://docs.github.com/en/get-started/quickstart/github-flow
• https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-pull-request-reviews-before-merging
• https://google.github.io/styleguide/

My Additions:

• https://help.obsidian.md/Contributing+to+Obsidian/Style+guide
• https://google.github.io/styleguide/docguide/style.html
• https://google.github.io/styleguide/docguide/philosophy.html

@Yilmas did not get a chance to really partake.

Select Q&A

With a free Org account, we don't get standard code-owners as an across the org feature. I do believe it is still available per repo though as long as its a public one.

So where do you want to start?

[sigrunixia]

https://www.conventionalcommits.org/en/v1.0.0/ is a part of SEMVER spec. I think Conventional would be easier for newbies than SEMVER pure.
We do want to encourage this use out of the gate.

My IDE which I commit to Git with helps me with these functions. I haven't checked if VSCode has similar.

[sigrunixia]

0.1.0 Will work then I think. It gives us a starting point.

Moving further into effectuating it: Do we want Dev branches?

[Yilmas]

Naaah, don't think that is necessary. Though potentially one could do a release branch.

[scottTomaszewski]

Some (GoLang) infer a 0 MAJOR version to be like the wild-west: you can add breaking changes and still call it a MINOR bump. Essentially the code in question is considered alpha/beta, so people shouldnt rely on the structure or API yet.

Once we go full 1.0.0 we should stick to semver strictly and consider what constitutes a breaking change. I think the obvious case is renaming a file, the headers, blocks, etc will break people's links. There is probably a good bit to think about here...

Sidenote on PATCH bumps - Ive seen a lot of developers get hung up on what counts (as a bugfix) here when it comes to breaking changes. My general opinion is if a change corrects the code to conform to the public documentation (written or implied) then its a PATCH bump - even if its technically a breaking change. For example, if the docs say "You can find a site map at note [[Site Index]]" and our site index note is called Sote Index - yes, technically a note rename is a "breaking" change, but the docs clearly imply that the existing note name is wrong. So correcting the note name is only a PATCH release. Im totally open to other ideas here, just offering a starting place :)

[sigrunixia]

That makes sense.

I think the next step is to start filling out the "Admin" repo with resources and best "practices policies". We'll keep it simple and build on it, but as was pointed out, we have a lot of new people and this can be intimidating.

[Yilmas]

Some (GoLang) infer a 0 MAJOR version to be like the wild-west: you can add breaking changes and still call it a MINOR bump. Essentially the code in question is considered alpha/beta, so people shouldnt rely on the structure or API yet.

Funny you should mention it, this is another reason to dislike Star Citizen, I just got another email saying they are in "v3.19" which is an alpha. At that point, why even user versions when you f' it up so bad.

[sigrunixia]

Signing commits. Yay or nay?

[Yilmas]

Nay, too cumbersome. And it isn't like we are building some software that needs to be secure.

[sigrunixia]

Note and will update defaults :)

[sigrunixia]

We will need to make some guides/recommendations on setting up new repos and maintaining established repos. Here is what I currently have for the PF2E SRD branch protection. Note we do not have access to enterprise features.

Any suggested changes that would be the "default" and then tweaked based on each repos need?

[Yilmas]

Those are good :)

[sigrunixia]

A conversation on Squash, Merge, and rebase with Ebullient got me wondering if we need to, or want to, restrict what types of commits we'll do/accept. I know it's a contentious issue in some minds. https://www.atlassian.com/git/tutorials/merging-vs-rebasing Sold me on rebasing as far as GitHub is concerned, but I want to know your thoughts.

[Yilmas]

I'm a strong believer in commit history. Rebasing allows people to hide their mistakes, obscuring faults for the reviewers.
However Interactive Rebasing done when performing local cleanups are a different matter.

At just about every job I've had since the conception of git, we've allowed merge on remote, and squash, rebase, etc. on local.

Or said in another way. What is the point of having a log, if you can rewrite the log at-will.

[scottTomaszewski]

I also really value commit history, mostly for the purpose of looking back at why/when things changed.

In that sense, I'm totally fine with people doing a rebase/squash on their (remote) feature branches, but once a commit is pushed to a mainline (develop, main, master, etc), it's set in stone. I'll actually encourage squashing a feature branch before merging into a mainline if it means others can look at the log and get a better idea of the feature change. I don't particularly care that it took a dev 5 commits to find the correct DB port; squash that noise 😂

[sigrunixia]

Oki doki. The feature branch is probably something we ought to implement. However, it's not something we can force unless we pay for enterprise versions. So education is going to win here.

Today I am going to be focused on filling out Admin repo with newbie getting started resources. A best/recommended practices for repo maintainers is probably warranted. Do either one of you have a few links that are go-to for that, which have not already been shared?

[sigrunixia]

Some quick updates:

• Resimplified the default labels. I'll leave the existing repos as they are for now.
• Working on Org-Wide Templates (which will be simplistic).
• Learned real quick to not have multiple SRD focuses at once. D: