"Thanks for the report! The problem is in link-to-file-in-GitHub. Do you want to send a PR to fix it? If not, we can fix it."
Sometimes they accept the proposal, sometimes not. It is a little more work to fetch the change, rebase, and merge it. But some people like the opportunity and perhaps may become a contributor in the future.
(If they don't accept, fix the problem soon and say thanks again with a link to the fix in case they want to see the change.)
I'm just not sure if this is something all open source projects - many of which don't have a lot of resources available - can handle. The very large open projects that already have a lot of contributors that can put in the additional time are definitely at an advantage here.
Usually I also put some pointers on how to get started, like "check such method in such file", or "have a look at that reducer action".
It doesn't take long to do this and it's been working pretty well. It's a very good way for new developers to get something done easily and to get familiar with the code base.
As of now there are 40 such issues, including 28 completed: https://github.com/laurent22/joplin/issues?q=label%3A%22good...
It's one thing to throw a tag 'good-for-beginners' on a bunch of issues, but the amount of effort going into some of these 'good first issue' things is astonishing compared to how tiny the issues are in the first place.
In my experience it unfortunately often hasn't been a net benefit for the projects I worked on. A "good first issues" takes up a lot of time to write and often never get addressed at all or it takes even more time to review and give feedback ultimately causing more work than addressing it directly since most "first issue" contributors do not come back to contribute again.
GitHub has done a lot to streamline the process of contributing to an open source project. I think what is still missing (or I don't know about) is an overall resource where you can learn about open source best practises (or just "Best Practises" since you should be using them everywhere) like writing tests, writing good docs, using conventional commits etc. outside of individual projects - and then in addition to the "Good first issue" label also indicate which one of those best practises apply to that issue, e.g. "This is a good first issue if you know about NodeJS, Mocha tests and Markdown".