May I suggest that you don't add more jobs to this list just now but instead focus on making the existing ones really junior friendly.

I just browsed through a few and have to admit that I have no idea at all how I would tackle those, partly because

• they are written from a perspective where familiarity with the framework and terminology is expected
• few if any helpful details are provided (yet)

I understand that preparing those for newcomers is at least as much work as to complete them yourself - so that takes some very determined seasoned contributors.

The reason why I suggest to move focus now: Most people who take a look at several of those jobs and don't find a way to tackle them will never come back.

As I really like using KDE Connect I will probably revisit the list, and I am prepared to have to acquire new knowledge and skills for valid contributions.

I totally agree that the jobs need a better description. This task is all about discussing what should be in there

What constitutes a "junior job" does indeed vary immensely. The maintainers or "lead" developers need to flag bugs carefully and appropriately. I've worked on junior jobs that ranged from string and icon changes, to adding a new API call to KWin. These were all referred to as JJ's, but they're definitely on different levels.

I know everyone is busy and can't always pay detailed attention to Bugzilla reports. But we all know coders for whom a junior job is a serious challenge for a newcomer.

I'm not a developer, so perhaps I'm missing important aspects here, but how about using a common template with the things that would interest people, so they can quickly review what's it about before going into the details?

For example:

• Objective: very short description of the purpose of this task
• Skills/Knowledge: what's required for someone to tackle this in terms of coding skills (or other related if not about coding)
• Time: rough estimation of time needed to complete the task
• ETA (if any): perhaps we want to include it in a specific release
• Difficulty: estimation of difficulty based on experience (e.g. easy for experienced developers in X, easy for new to X, etc) or another parameter
• Contact Person: tag the person most suitable to mentor those interested in this task.

This could be on the top of each task and you can further expand below on the specifics and technicalities.

I've been talking with @dkardarakos on this topic and he mentioned they are discussing similar things in Plasma Mobile, I've asked him to leave a comment here as well with what they came up with.

It would be nice to end up with a common approach for this to be used throughout KDE.

Following a discussion with @bshah about T8685, we opted for revamping Plasma Mobile phabricator tasks. The status of many tasks has been changed in order to avoid offering to the potential contributor a task already done.

The question-answer system suggested in T8685 will (potentially) use the phabricator API and collect the open tasks of Plasma Mobile by parent task. Each task should belong to a parent "generic" task (e.g. Hardware functions, Performance improvements, etc) - as is currently the case.

To find out what we need to add to the task, we executed a scenario of a university informatics student that wants to contribute. We selected a random dev task and, acting as the university student, I asked him all that I needed to start working on the task.

We concluded that we needed development tasks that:

• Clearly describe their objective
• Describe the technical details
• Provide references to, mainly technical, resources
• Provide a simple and easy to follow guide to set up the development environment

As a result, @bshah has already done a tremendous work revamping Plasma Mobile phabricator tasks. Check https://phabricator.kde.org/T6945 T6945 as point of reference. In the task details, a set of links are offered to the contributor in order to have easy access to the technical resources needed.

Instead of "requiring" a technical background, we opted for mentioning that the contributor should be just "willing to learn Qt/QML, CMake". We are going also to create a page where technical resources to these technologies will be provided.

We also started working on a development environment setup guide. Moreover, @bshah started creating a ready-to-use precompiled VM, to be used as the dev environment.

P.S. @neofytosk let me express my disagreement with any reference to Time, ETA, etc. As regards to junior jobs, the potential contributor may not be quite familiar with the foss principles. Apart from the psychological effects of mentioning time (how will a new guy feel when the task is completed after 15 days while the task creator mentioned 2 days?), adding deadline-like things to foss contribution tasks offered to facilitate onboarding may lead to a distorted picture of the free software ethics.

Maybe we could add a "Junior Job" tag to phabricator? At the moment junior jobs are spread all over phabricator and hard to find. With a global "Junior Job" tag we could collect all these jobs in one place and new contributors could search threw them to find something that fits them.

+1
We had a similar discussion in Akademy! Since string tags can't be added, we have to create either a group or a project.
Then, we may use the phabricator API to serve the junior jobs wherever needed. And, why not, create sth similar to the findyourway of plasmobile for KDE junior jobs in general.

Something else that might be very useful in this regard, would be a way to flag, tag, sort, ... tickets by programming language or other skills one would need to accomplish a task.

We now have a Junior Job board !

https://phabricator.kde.org/project/view/294/

In T8686#164113, @fabianr wrote:

We now have a Junior Job board !

Well, the workboard is still empty... Maybe you meant "project/tag" instead of "board"? :)

In T8686#164113, @fabianr wrote:

We now have a Junior Job board !
https://phabricator.kde.org/project/view/294/

This is great, thanks for making it happen!

In T8686#161650, @fabianr wrote:

Something else that might be very useful in this regard, would be a way to flag, tag, sort, ... tickets by programming language or other skills one would need to accomplish a task.

And definitely +1 in this, as it is something that we are considering for the new landing page (T9776) as well.

FYI, I've asked @bcooksley and he was kind enough to create the workboard immediately, so everyone can now easily view all the pending junior jobs.

closing this as it is now done. If we end up switching to gitlab, we should remember to reintroduce a similar tag.