Perhaps it could also pull Junior Jobs from Bugzilla? It’s a good idea, having it readily (and semi-permanently) available. I don’t know if we could get it done in time for Plasma 5.13 (assuming the idea is approved).

+1 from me

One of nice example I found earlier : https://howcanihelpubuntutouch.io/

Another website like that is https://whatcanidoformozilla.org

If we want to create a website (even it it's something like myfirstpatch.kde.org), we should put a link on the user's desktop at installation. That's relatively inoffensive, easily removed, and requires less coding than a desktop widget.

In T8685#141599, @sharvey wrote:

If we want to create a website (even it it's something like myfirstpatch.kde.org), we should put a link on the user's desktop at installation. That's relatively inoffensive, easily removed, and requires less coding than a desktop widget.

+1

TBH, my suggestion is primarily focused on the facilitation of a really fast and simple first contribution. Like the case when we learn a new programming language, almost always we try to run a "hello world" example, without having any real knowledge of the language or having read (almost) any page of the language reference. After the successful execution of the “hello world” , we feel a little bit more comfortable to continue studying. It's the "hello world" psychological effect accompanied with the feeling of membership and commitment to the KDE family that the solution tries to reproduce .

Nevertheless, following the example of the sites suggested, the solution may be extended with an extra initial page. In this page, the widget/web page will ask sth like "Time available" and provide a set of options, e.g.:
1 15-30 minutes
2 No time limit

If the user selects option 1, the flow already suggested will be presented.
Otherwise, a set of questions like the ones included to the web sites https://howcanihelpubuntutouch.io, https://whatcanidoformozilla.org will guide the user to a different community.kde.org page.

The translation teams have said various times in the past that translations from random people in the internet with no commitment usually just bring in more work than they help since they totally fail at syntax, style guide, etc. I wouldn't be sure this has changed at all.

I mean would you let people edit code form the internet and submit a patch directly without having them compile and try it whatsoever? Probably not, so why would it be different for translations?

As a relative newcomer (January), this is a very real and very powerful
thing. We should do whatever we can to encourage it. When my first
commit got landed (a simple plasmoid fix), it was a great feeling. Now
you'll probably never get rid of me.

There's still the slightly nasty (and so far, unsolved) problem of
getting a functional development environment set up. Even a simple
string or icon change needs a bunch of dependencies installed for the
product to build & test. The list of prerequisite packages is dauntingly
long - assuming your package manager installs them all without error or
further confusion. And then tracking down any extras added to the git
master since the wiki page was last updated.

In T8685#141924, @aacid wrote:

The translation teams have said various times in the past that translations from random people in the internet with no commitment usually just bring in more work than they help since they totally fail at syntax, style guide, etc. I wouldn't be sure this has changed at all.

I mean would you let people edit code form the internet and submit a patch directly without having them compile and try it whatsoever? Probably not, so why would it be different for translations?

Before adopting the suggested “first-commit solution” (or any alternative) I think that it is important to consider a set of things.

At first, the solution is based on the assumption that the first commit is different from the rest, since it assumes that the distance from 0 to 1 is not equal to the distance from N to N+1 (in term of commits) and it is of significant psychological importance. If we disagree with this, we should reject the solution.

In case that we agree with the assumption, it would be useful to try to respond to the following:

• Introducing such a “fast and simple” way for the first commit will confuse future contributors? Will it prevent them from adopting the proper contribution workflow after the first commit and lead to poor contribution quality?
• The same applies to existing contributors or/and mentors. Are we able/willing/ready to support such an alternative for the first commit?
• In general, adding new members to a team, induces effort by the existing members (in the beginning). Adding members via such a kind of onboarding procedure means extra effort (heavy? light?) Is it worth it? Should we avoid increasing the burden on existing members?
• Is this solution suitable for all/some/none of KDE projects/teams?

I don't think anyone's proposing an easy-but-broken method of brute-forcing the first commit. Rather, I think we're all discussing how to make it easier to get started the right way so that first commit is not only easier, but also conforms to KDE best practices.

It's indisputable that the first success in a complicated new venture is both a formidable gate, and also acts as a psychological hook for future contributions. As mentioned earlier, that's why "Hello World" programs exist.

Also the whole premise of this onboarding goal is that adding more members is a net win, even if it requires a bit of effort up front to help people get started.

even if it requires a bit of effort up front to help people get started

Besides, overcoming a challenge makes the success feel more worthwhile... Or that is what they taught me at teacher training school.

That said, a process is only insurmountable if it is not adequately documented. So maybe look at documentation, create easy to follow walkthoughs and tutorials first, before changing anything in the current process? This would also server to work out kinks in the process, find steps that may be redundant or can be simplified.

A process is only insurmountable if it is not adequately documented

Fully agreed.

Something like https://community.kde.org/Infrastructure/Phabricator#Posting_a_Patch_using_the_website will require more documentation then, including screenshots, I can do that when I have the time (admittedly, I have been postponing several tasks lately, so if anyone wants to do this first you're free to do so).
Reasoning: people who prefer GUIs for their workflow or are intimidated by the terminal would be less exposed to code, and the code they would see would be easily reproducible and clearly instructed.
Caveat: it depends on whether Invent will fully replace Phabricator for code and when, if it's a full replacement and if it's in a few months, such effort would be a bit redundant.

I would not invest more time in documenting Phab given the impending GitLab transition. Putting that effort into https://community.kde.org/Infrastructure/GitLab would be much more worthwhile IMO.