Junior Jobs
Open, Needs TriagePublic

Description

Hey,

I started marking tasks on the KDE Connnect Workboard as junior jobs. I aim to provide structured information on how to approach the problem and where to get help/information.

Ideally every project would do that and provide the information in a unified way, so I would like to discuss which information is relevant.

Here's my initial proposal:

  • Clear description of the problem, desired outcome
  • Which repositories are affected
  • Which folders/files are affected
  • A basic outline of the approach
  • How to test (partial) solutions
  • Maintainer/relevant people for the affected code
  • External resources (SO discussion, tutorials, docs, tools)
  • For UI changes: Mockups

Questions, comments, suggestions are very welcome

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.

neofytosk added a subscriber: dkardarakos.EditedMay 19 2018, 3:22 PM

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.