As part of the changes to the trial process for newcomers, we are introducing the concept of “trial projects”, meant to replace the trial period, and allow us (and the candidate) to conclude the evaluation sooner. This is important to accelerate the recruitment process, but can only work if we are actually able to properly evaluate a newcomer once the trial project is over, with a similar level of accuracy as what we have now for the end of trial review. Which in turns means that we need good trial projects - so it’s worth spending some time brainstorming this together.
For trial projects to work, as noted on the merge request review for the recruitment process change, the project can’t just be a “big newcomer friendly task”, or we won’t have enough to judge during review:
The project specifically shouldn’t be “newcomer friendly”. That’s a part I liked from @bradenm 's proposal - we used to test newcomers on something difficult immediately. Good senior developers who will fit within the team are able to take this on – we regularly have good examples of this. On the other side, the “newcomer friendly” category we came up with helped some newcomers being less lost at the beginning, but that tends to only delay finding out they can’t take on harder work later on. If we want to be able to provide the same level of judgement on a 20h trial project as we do after 2 months of work, this trial project needs to be at least as hard as what we ask of newcomers now to approve them as core team members.
So we need large tasks that require significant work and skill from the candidate – including managing to acquire context in a short amount of time – ie a 8 point ticket? The projects also need to be real work, but work that doesn’t have a client deadline during the current sprint – this way, if the candidate fumbles, it can still be assigned to someone else the following sprint, without anyone having to suddenly take over a lot of work as a sprint injection.
Not easy, isn’t it? What do you think some good projects or topics for these types of tasks can be?
In any case, that would likely require thoughts from epic owners to find the right tasks - possibly including more advance planning with clients, to have more work lined up earlier, which we could then safely pass on to candidates. On the plus side, epics who are currently having trouble completing enough work due to capacity issues could get a boost, and in a way that’s safe budget-wise (since if the candidate doesn’t work out and the work has to be taken over, we’ll simply log the time on a separate recruitment budget).
- I’ve suggested giving upgrade and maintenance work as trial projects.
- Also, maybe some of the current paused epics could get some work done this way? (It’s better if there is an upstream or a client using the work, to test that too.)
What else? Are there epics owners willing to help feeding some trial projects?
@shimulch @jvdm @raul since you have tasks about this for this sprint, could you coordinate figuring out the epics & projects we’ll try out from your cell, within the current thread? CC @braden since you’re reviewing those.
Another related topic is the follow-up on the bounties we discussed some time ago. It was within the context of providing a way for candidates without contribution experience to satisfy the requirement to have a merged upstream contribution before being considered. It could potentially be another source of trial projects.
Another application for bounties could be to provide a way to open up to work with more junior developers. A lot of the tickets generated by dependencies & release upgrades upstream are small and simple. Currently we contribute our share through the release upgrade epics & core committer time, but that’s probably overkill – it could maybe be better to offer those to candidates willing to spend some (paid) time becoming familiar with the platform, contributing open source code, and generally improving their skills. More junior developers could take those tickets on an ongoing basis, until they have acquired enough experience to consider tackling bigger tasks – like our trial projects?
CC @nizar since this could end up being linked to the community liaison role, to list upstream issues for bounties & coordinating upstream reviews (which we should participate in as core contributors).