My thinking/hypothesis is that of the total drain on oss project maintainers, some is attributable to a lack of submitter will and some to a lack of submitter skill.

The lack of will might only be fixed by a visit from the ghosts of Christmas past, present, and future.

But, the lack of submitter skill has more correctable root causes.

Perhaps some of the skills below

I am self-aware enough to know this post may come across as feigned helplessness similar to what OS maintainers face every day. The community has been super welcoming, and I have work to do to earn trust that I want to help with the problem statement above.

Last - as far as the ideas below - I don't know what I don't know. There are better ways to progress the hypothesis above than what I have written below.

How to Walk through a repo

Julien's encouragement to dive into a repo. It can't always be the guided tour you get from a senior dev (or from his NuxtNation video!)

Assuming you're interested in learning from it or actively troubleshooting an issue

General interest in Learning from a Repo

Looking at Tests and the Playground

Example: How to run the playground and try something out.

Using github search to find how it's handling a use-case similar to yours

Example: How to share a Zod validator between server and client in Gavarnie. I never thought to do it that way!

Troubleshooting your implementation

Creating a minimal repro

There are existing resources out there for this in - Why Reproductions are Required. The message really fuels a lot of this writing. I don't want to be a burden. I'd like to equip myself to, in order.

Building up or whittling down parts of your project to isolate the behavior you're not expecting. This seems to be a skill that you need to build your app in a way that makes isolation easier.

For example: I love when maintainers share examples of good minimal reproductions. As a learner, I'd like to see the full implementation to see how they carved it down. I can totally see where the work to isolate a problem for a minimal repro yields a solution not requiring opening an issue. I really want to beef up my skills to thoughtfully isolate. I typically build things so poorly that ripping out something like auth or a data source means nothing works. But, it would be unreasonable to ask an issue reviewer to plugin their own OAUTH credentials in a .env.

How to investigate what's triggering behavior

Example - I was using PInia Colada and suspected I was fetching data 2x. But, it was actually a super cool feature that refetched on window refocus. I am embarrassed by how long this took to find out, but I basically added a line to my fetch function to throw an error so i could have a browser breakpoint. There has to be a better way 😅

How to follow stack traces with murky lineage

Skill issue here for sure, and maybe its from bundling / compiling, but I realize these stack traces and source maps exist to make me better at troubleshooting.

How to better leverage the IDE

When I am troubleshooting, I tend to lose track of all the changes/steps I've made to triangulate what's wrong. My "method" is not very scientific and often leaves artifacts behind. It'd be like a search and rescue team that kept finding only their own footprints.

I've tuned into a few of Daniel's bug smashing streams and always pick up tips. There's a window that shows (I believe) unstaged changes since last commit. That could help keep track of footsteps.

How to better leverage Git

Similar to above, but what tools are there to help when something might have gone wrong. @antonio mentioned git bisect which sounds awesome.

Going upstream

Pnpm patch seems very valuable. As a novice, my usage is limited to when I've been blessed with very clear instruction on how to use it.

Example: these folks keeping unocss-preset-daisy alive are amazing! feat: support daisyui v4 by ameinhardt · Pull Request #39 · kidonng/unocss-preset-daisy

Expanding on that, I see where repos such as vite carry patches, but I wouldn't even know where to begin to say "If i patch ___, that will fix/allow me to do this until further notice".

In Anthony Fu's article, he talks about examples creating a PR with a failing test. Would love to know how to best accomplish that. Assuming it could include

How to get setup contribute (link)

How to evaluate if the playground and test fixtures have sufficient info to reproduce

How to create the failing test

How to submit the PR (link)

Mindset

There are already some great sources on the burden and drain on OS maintainers. Learning this context can really help a novice as they learn skills above.

Sources

Julien's NuxtNation video and reply

Evan's talk on support/help type contributions to the open source community

Anthony's "Reproductions are Required"