openinf / .github Goto Github PK

How this got so out of hand so quickly is impressive.

Witness the barrage of questions that get thrown your way during VSCode bootup, then even more during project bootstrap, and the remainder is uncharted territory.

Here's why: the canonical storage location for our standard project label packs happen to be provided by the solution we have chosen for managing default github repo settings; namely the GitHub App simply named "Settings", which syncs repository settings defined in .github/settings.yml to GitHub, enabling Pull Requests for these now-serialized repository settings.

i have been meaning to do this for a very long time:

every project repo transferred under @OpenINF umbrella has to undergo a certain procedure before we can properly maintain it or bring it up to a recovered state where we may begin to place within the context of our project lifecycle(s); let us flesh that out (minimally at first, then more-so in the short-term)

Refs: https://github.blog/2018-02-22-label-improvements-emoji-descriptions-and-more/

we have spiffy labels in some repos now, but they are not evenly distributed; we should prioritize keeping them nice and safe here w/ directions on how to apply them everywhere else:

• https://gist.github.com/DerekNonGeneric/2ad0a083150e1ecce1314bca8fed1ed0
• https://github.com/rollup/plugins/blob/master/.github/labels.json
• rollup/plugins@7b5bc1a#diff-e2fc5abdfc47896652566c565d68af637e56e947a154572f33f7491bcbfaccbaR1

syncing scripting:

• https://www.npmjs.com/package/@google-automations/label-utils
• https://www.npmjs.com/package/github-label-sync
• https://github.com/himynameisdave/git-labelmaker
• https://github.com/Financial-Times/github-label-sync
• https://cli.github.com/manual/gh_label

@DerekNonGeneric, suggest rfc{1123,3339} date format instead (?)

Originally posted by @OpenINFbot in #655 (comment)

Our tasking situation here will get a lot more impressive and be less-incomplete once the changes i had proposed in ampproject/amp.dev#3346 finally make their way over here. That is quite a high priority since it precludes the org-wide adoption of our tasking structure here. The funny thing about our currently-incomplete tasking situation here is that it is very home-grown, and although it may have already outgrown its original training wheels (the nps solution), they are still fully-functional and even still used by the CI to this day.

Apparently pnpm's lockfile never got updated as the package-lock.json normally would w/ PRs made by @dependabot & @renovatebot. They have now become desynchronized w/ only the pinned deps in the package.json being accurate.

Running the command npm doctor helps to diagnose several problems often faced by package repos organized like this one.

Two things it looks at currently cause their checks to fail:

• running latest LTS version of node
• running latest GA version of npm

We fail these since we have been sticking to Gallium 16.x LTS.

Apparently the CI's in need of repair most likely due to breaking changes affecting the APIs of the plugins employed by the script that evaluates Markdown files: “verify.md” —

The script called "verify.md" which runs "node build/tasks/verify/verify-md.mjs" failed with exit code 1

 — the context of the above error message viewable in the below image.

Self-assigned; however, this will not be receiving our final intended solution to the pre-submit testing of Markdown expected to be done by our CI; commits addressing this issue should not be expected to implement our final ideal solution…

How we expect to achieve our final ideal solution begins to be hashed out by myself in the following thread on the topic.

🔗：https://twitter.com/DerekNonGeneric/status/1660506159978086403

So, yes, this codebase will need to undergo “comprehensive deregulation”. We do not plan on having this be the location where rules are defined or enforced/triaged, but more on that a little later tonight once we can get a green CI for merging our translations…

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• build(deps-dev): bump babel monorepo to v7.24.7 (@babel/core, @babel/eslint-parser, @babel/plugin-syntax-jsx, @babel/plugin-transform-modules-commonjs, @babel/preset-env)
• chore(deps): bump all (actions/checkout, docker/dockerfile, dprint, editorconfig-checker, eslint-plugin-json-schema-validator, eslint-plugin-jsonc, eslint-plugin-promise, eslint-plugin-regexp, pnpm, prettier, returntocorp/semgrep, ruby, ruby/setup-ruby, typescript, unified)
• build(deps-dev): bump eslint to v9.5.0
• build(deps-dev): bump typescript-eslint monorepo to v7.13.1 (@typescript-eslint/eslint-plugin, @typescript-eslint/parser)
• build(deps-dev): bump eslint-plugin-unicorn to v54
• chore(deps): lock file maintenance
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Currently, this field specified in package.json:

{
  "packageManager": "[email protected]+"
}

Output:

derek@WIN-QCQNRDEGMKF:~/projects/openinf-github-dotrepo$ corepack enable
derek@WIN-QCQNRDEGMKF:~/projects/openinf-github-dotrepo$ pnpm i
Usage Error: Invalid package manager specification in package.json; expected a semver version

$ pnpm ...

Seeing as how this did in fact pass the validation, it should be noted that the regex for validating this field (package.json schema on schemastore) is wrong when validating this field…

This is not a pnpm field, though; this is a corepack field, which is very confusing…

Refs: https://pnpm.io/package_json
Refs: https://github.com/nodejs/corepack#when-authoring-packages

/cc @arcanis as am currently unsure what is going on here (would like to specify global npm is req'd)

I mentioned to @yuvilio (via email) that we would be striving towards maxing out OpenSSF Scorecard.

Let's be sure that while resolving #147 (specifically the deps automerge), those principles are respected (inlined for convenience):

At the time of attempting to implement a check using this toolset, these packages were still in their infancy w/ unstable guidance coming from their documentation… ^{1 2}

No biggie; this all looks to have [somewhat] stabilized since then:

• https://www.npmjs.com/package/@shopify/cli (re-published ~15min ago)
• https://www.npmjs.com/package/@shopify/prettier-plugin-liquid (last published ~2wks ago)
• https://www.npmjs.com/package/@shopify/theme (re-published ~20min ago)

A cultural diversity experience awaits (!) since it never did work…

Refs: https://github.com/OpenINF/.github/blob/ebeb8fe354a7b2046e778e0376fd468ccdb986b8/package.json#L30C6-L32

Serbian is practically the only European standard language whose speakers are fully functionally digraphic, using both Cyrillic and Latin alphabets.
— https://en.wikipedia.org/wiki/Serbian_language#cite_ref-18

This seems to be a unique case in natural languages, but the Serbian language can be expressed in either Latin (sr_Latn) or Cyrillic script (sr_Cyrl), so what i said about “two-letter codes, one per language” in #34 (comment) is a little bit incorrect due to this edge case. I think we will need to specify which one of the alphabets we are using when making these translations to prevent mixing them.

/cc @emmitrovic as i am unsure which one we should use (is one preferable or maybe we need both?)

I am not exactly sure, but the only other time this may come up elsewhere is when distinguishing btwx Simplified Chinese (zh_Hans) and Traditional Chinese (zh_Hant)…

/cc @septs as this file naming scheme seems to be gaining widespread adoption (guideline may be needed)

To be clear, this is not about localization in the sense of wanting to distinguish btwx Portuguese from Portugal (pt_PT) and Portuguese from Brazil (pt_BR), which use the same alphabets. On the topic of Portuguese: I was hoping to be able to only use pt and leave the translation style up to whomever does the translation. For example, some things sound better in pt_BR and others in pt_PT, so if we can avoid making the distinction, i would prefer that.

/cc @ErickWendel as am unsure if this would be practical (am still learning and unsure of edge cases)

Any additional insight you all can provide would be appreciated!

Codacy is configured to use remark-lint (in addition to our current Markdown linter), which appears to be using the default rules since we currently lack a configuration file for it in this repo. Some Markdown lint rules are unique to this linter that we could benefit from, so we should have it properly configured to pass checks for that tool. Fortunately, we had already been using this Markdown linter in our site repo, so may be able to copy that configuration over and add any additional tasks or rules to ensure we can run it locally before pushing up any new commits.

The contribution guidelines surrounding licensing are too simplistic and unclear.

This is also not the whole story about what we currently do. Expand and clarify.

So much depends on the outcome of our issue named ⚖️ get real about license guidance in contribution guidelines.

The public is clamoring for us "get real" because the topic of Licensing a Repository could not be adequately addressed within a CONTRIBUTING file w/o completely taking over the majority of the document's real estate due to the sheer quantity of content necessary to adequately address the various topics involved and be successful in pursuit of the endeavor.

Requested new document: Licensing a Repository (Rebranded w/o Pitfalls)
Alterations summary: Most are already known to document editor/remaining to be raised during review.

🏛️🔗：https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository

Would you like to include a changelog?

A changelog contains a curated, chronologically ordered list of notable changes for each project version. To make it easier for users and contributors to see precisely what notable changes have been made between each project release (or version). Whether consumers or developers, the end users of software are human beings, who care about what's in the software. When the software changes, people want to know why and how.

see https://keepachangelog.com

I owe our entire community an apology. Recently, in an overzealous attempt at efficiency, I deleted a detailed record related to scaling our ADRs without adequately considering the impact. If any of you wish to give input on appropriate amends or share constructive criticism I should hear, please come to me openly. We shall become wiser together.

At the most fundamental level, i will:

• restore/recover the deleted [notes] on this critical engineering issue by day's end (we use pacific time here)
• resolve any blocked progress
• incorporate any updated details provided (playful satire came quickly; reception has been positive/supportive; proposal for @ocaml based stack was fielded & well received)

Consider the record returned in full. ✅

This initial action, however, only partially encompasses the amends entailed. I openly welcome any additional constructive feedback on rectifying my mistakes in judgment - be they replenishments in process, safeguards against repetition, or building renewed understanding. My responsibility in this situation stretches beyond data to trust and respect among teammates. Please come to me freely with thoughts so we may walk this path to redemption together. With open ears, hearts, and minds on all sides, I am confident in our bonds moving forward.

Woo foo!

The 5 extension(s) below, in workspace recommendations have issues:

• knisterpeter.vscode-commitizen (not found in marketplace)
• lunaryorn.fish-ide (not found in marketplace)
• mrmlnc.vscode-json5 (not found in marketplace)
• skyapps.fish-vscode (not found in marketplace)
• travisthetechie.write-good-linter (not found in marketplace)

it's a doozie bc we are mid-migration to eslint 9

This has been an ongoing issue, and we (@OpenINF/wg-a-team) have started working on this in other channels and repos (e.g., our yet-to-be launched @OpenINF/standards repo).

I want to get this taken care of here and now while taking those learnings back to that project.

i noticed that jekyll plugins (and mostly themes) have defined naming conventions:

🔗 https://jekyllrb.com/docs/themes/#installing-a-theme

• jekyll- prefix for all jekyll plugins (perhaps postfix -plugin)
• jekyll-theme- prefix for theme plugins

Fisher plugins should probably also retain some convention (thoughts include):

• fisher-gap
• fisher-plugin-gap
• fisher-gap-plugin

maybe this would be our ideal name here (based on repo name):

• OpenINF/fisher-gap-plugin 🔗🐙

/cc @jorgebucaran

@restyled-commits
style: apply changes from whitespace restyler
b1c34ad

Signed-off-by: Restyled Commits [email protected]

This commit message is incorrect and must be corrected. We must tame the bot (sounds fun)

We have regularly been receiving dependency update requests from the following:

• @snyk-bot

• @dependabot

• @renovate-bot

They each have their own way of titling their PRs and sometimes those titles match the first line of the commit message (other times they do not). The request is to fix these requests to match our needs.