Ok. That sounds like it could run concurrent to our existing recruitment process, and might be worth trying. It’d be a great way for people who are peripherally interested in making contributions but otherwise wouldn’t be able to justify the time to make them. They might not even specifically be trying to apply in this case, we’d just reach out to them as a contact afterward, yes?
1 Like
We can be up-front about the hiring part, but yes, I don’t see why we should make the bounty list exclusive to people that want to apply.
1 Like
I like this idea. It does sound like it’ll take a bit of dev/process building work to get going, though. Would be curious to get more of the recruitment managers to weigh in, and see what we can schedule in the future.
Maybe @joao.cabrita or you might want to run a discovery on how to implement this so we can get an idea what it would take to make a reality?
1 Like
If nobody else steps in, I can try and find some time on SE.247, yes. But as you suggest, it’s a good idea to get the other recruitment managers’ takes on this (@usman, @paulo, heads up!), and of course Xavier’s, as this is going to cost money, after all. (Are we still allowed to ping him here in the forum for things like this?)
@adolfo I don’t think we’re supposed to ping him here, but what you could do is create a task to review the discovery and add that to the management board. He DOES, however, have a task to review this thread, and I think he may be doing that next week.
I’d go ahead and create the task now and schedule it, along with a management task for review. He should be through the thread here before then and can tell you to cancel the plans if he has an objection before then.
I like the idea of paying people to complete and merge a small open source bug/feature before they start. I’ve actually mentioned this to a couple people recently. As @Fox mentioned, we used to do it that way. Now that we have core committers, we can do it again, and I think it’s a good idea. BTW we can also assign work from any of our own projects too (like Ocim, or the Workflow manager), since they’re all open source - but it’s ideal if it’s Open edX and they can demonstrate some communication with upstream in the process.
5 Likes
+1 for the idea. It would be beneficial for newcomers too, as they could taste how we work, how our processes are working what it means to contribute to a big open-source project and they could decide if it is something they are enthusiastic and committed about.
I certainly like this idea, and it could be helpful for improving our recruitment process, but since it’s a longer term project, I’d like to circle back to asking about more short-term solutions. Are there any quick changes or interventions we could do? Is anyone willing to change the hours allocation for their client’s budget? Does hiring a third party recruiter to help us find candidates sound like a good idea? Is there anything else we could do to address the acute side of this issue?
Hey @Fox, I really like the bounty idea. This is something that has been discussed a few times and I wanted to make a recruitment experiment around it. But that’s more long-term and will probably need a few iterations to get right.
In terms of short-term solutions, I’m looking into automating part of the recruitment process to get us increased agility in getting back to candidates, as we are seeing many accepting other offers before we can get them interviewed.
All: I split the topic in order to place capacity planning in its own thread, which I’ve marked private since it may contain information about long term strategies/planning on behalf of clients. The rest of the discussion can continue here but if there’s a particular item that may need private discussion, we can create another thread fork for that.
@paulo That’s good to know on the recruitment front. If we’re having trouble responding on time automation would be incredibly helpful!
2 Likes
@Fox Thanks a lot for taking the lead on bringing up this topic, and sorting it out! Huge kudos for that, it is indeed one of our main challenges currently. And it’s true that we have focused on increasing the visibility of the ad, but there are quite a few other things that we can explore to help fix that.
And thanks for all the insightful comments and ideas btw – it’s a dense thread, which gives plenty to think of and experiment with to solve this. I’ll try to cover the main points brought up so far:
Job ad & attractiveness
The job ad could definitely use a refresh, as it only had a few changes to it over the years. I like the new version a lot more, it gives a much better idea of who we are – and that makes sense, as this is something we have progressively established over the years. :) I’ve also done a pass earlier today (thanks for reviewing my additional suggestions and merging them already btw @Fox , that was fast! :) ).
Btw, note that we haven’t actually had a low number of applications - we have currently ~30 applications per week, which is more than what we had in previous years, and even quite regularly good candidates that we bring in for the trial. But a higher proportion of the candidates we accept seem to pick a different company before signing their contract – maybe because there are so many more companies recruiting remotely lately, so people who want to work remotely have more offers? It might also be more difficult to stand out next to the big name brand corps, who used to be very reluctant to remote work – and who still don’t really provide a good environment for it (or at all), but who provide a shiny reference for the resume and inflated paychecks. Also (or maybe as a consequence?), fewer of the candidates who joined passed the trial, even when they looked very promising in the initial.
To help fight this, working on showing what makes us different, and a nice environment for those who would fit well here, is definitely a good move – so things like improving the job ad, the handbook, or the website are definitely good ones. Actually:
- About the job ad, I’ll update all our job postings next week, once we have had a pass of proofreading done by gramlee
- About the website & handbook improvements, would you want to take on an epic on this @Fox, with maybe @gabor since you suggested it, with @Ali @cassie @larrybotha? This would have priority over the other internal epics UX work, as recruitment is definitely blocking them currently, on the development side.
As a side note, I’m also still regularly looking at expanding the reach of our job ad to new boards – and I’m also going to try something new, which is to use more traditional ads, not specifically job board ads, to reach different profiles – people who might not even know yet they want a job here. 
I’ve reached out to ReadTheDocs to give it a try – we’ll see how it goes, but it could be something to extend to a few places where developers go.
Hiring contractors
+1 to try to fill the gap with contractors – though it’s true that the tricky bit, just like with hiring normal team members, is to find good ones (or for them to find us). But yes, even though we generally prefer to work with full permanent team members, especially for core functions like development, it still could make sense to temporarily ramp up the number of contractors in the team while we sort out the recruitment.
On this, @raul came to me with an interesting proposal – would you like to explain it here?
Bug bounties
That does sound like a useful experiment to try. One thing that I’m a bit wary of with it is that bounties are based off a monetary incentive – and part of the reason why we have third party open source contributions as a prerequisite is that it takes a specific mindset for someone to set aside some of their (or their employment’s) time, which for developers is always being competed for by a thousand different things, and fix a bug not just for themselves, but also publish it publicly for others to reuse, and go through the whole process of submitting it, getting it reviewed and accepted by an upstream. Most people “don’t have the time” (or, at a minimum, will accept to keep working for an employer who doesn’t allow this type of contributions) – that’s precisely what makes someone who still finds the time (and courage) to contribute special. They want to share and contribute, regardless of the external incentive – and that’s part of what makes us who we are, I think.
That said, we can see how that goes. A third party contribution is still an achievement by itself, and we don’t filter out people who did their contributions as part of a previous job anyway, so there is no reason we couldn’t still find good people this way. I’m guessing successful open source bounty hunters do this for more than money, like we do…
What would be good upstream tasks we could start with? Maybe some of the pending release group bugs for Lilac @adolfo? If we can build a list of tickets to submit, I can take care of posting the bounties. Ideas for the amounts to give for each of the bounties, or time estimates for the effort, would also be useful.
Headhunters & reaching out to potential candidates
I’m ambivalent about that one, as headhunters tend to simply spam a lot of people, and both ways (sending also lots of irrelevant candidates). They are also extremely expensive, taking months of salaries for any hire – and many definitely wouldn’t agree to a refund for all of the newcomers we don’t confirm as core devs… If some of you have worked with recruiters you liked (either to recruit, or be recruited), let me know though, we can experiment. I’ll also try to figure out if I can identify someone for this.
Alternatively, we could also start looking ourselves for potential candidates – through our job postings, we already have access to some databases. @paulo @usman @adolfo Is that something you would like to look into, as recruitment managers? Or maybe others would like to help punctually on this?
Organizational development & consultants
Yes, if we had taken the usual path of most normal companies, these might be useful, but for our model we are one of the experts. (Though not the only one, so it could be worth reaching out to other similar companies?)
We could potentially sell our own services on this one day – but yes for the current issue that wouldn’t really help us solve the problem, we have already too much to do :) We also have to show that we can grow with our model first. I don’t have any doubt that we can, we have already passed some pretty difficult growth milestones in the past, but we actually need to tackle and solve those problems – which is actually what we are doing here. :)
For the transmission of our knowledge, it might also make more sense to start by publishing it, either as text on places like the blog or the handbook, or with courses, like we are doing with our knowledge about contribution in the upstreaming MOOC. If those work out, we can develop more like it over time. It also makes sense to release the information freely, rather than asking people to pay individually for us to release our knowledge to them – which sounds like a more proprietary approach ;p
Upstreaming MOOC
Talking about the upstreaming course, this is also part of the strategy for recruitment, although on the longer term, since it will take time to complete it and release it. Part of the idea is to attract people interested in contributing to open source, and maybe getting a job in open source – and, not coincidentally, one of the criteria for completing the course is to have a merged contribution to a third party open source project… precisely the main requirements for recruitment that is the trickiest. It would also hopefully raise our profile within the open source community, and get us more known of open source enthousiasts – especially the ones stuck in horrible proprietary corporations. 
Addressing newcomer feedback
We do reliably gather (and regularly address) the newcomer feedback at Issues · opencraft / documentation / public · GitLab – even when they provide feedback at the exit 121, if it’s relevant I usually ask them to post it there, or in the forums if that’s a more general issue.
It’s definitely a good opportunity to do a pass on those though – even if we didn’t have any tension on the recruitment, as we’ll need to onboard quite a few people over the next few months anyway, and they would benefit from it. @gabor you have a pass coming up on this, as part of SE-3755, right?
That said, iterating on the onboarding has been an important focus from very early on, and generally people who are good are able to work things out, even at times where things weren’t as laid out as they are now – so I’m not sure if this will change our trial retention rate, generally it seems to have been issues with the person/fit, rather than the process? I could be wrong, though.
1 Like
I’d be definitely up for it!
In case the relationship is good with the contractor, it may happen that they would be up for joining as full-time contractors, therefore this could be an additional way of hiring.
I would be up for that too. The earlier we find good candidates and core members, the earlier we can jump on more client/internal work as we could plan better – at least this is what I feel.
Yes! Also, I started to open a bunch of tickets this sprint and will open a lot for the upcoming sprints, though we are on a tight budget right now for the epic. I’ll open tickets for all the relevant issues and I’ll update you on the epic @antoviaque.
1 Like
Yes, that’s more what I had in mind–I agree that hiring a consultant unfamiliar with remote/async would be a waste of time and money. How about we reach out to Gitlab’s CEO, and ask him to assess our processes and handbook? The way they work is similar to OpenCraft in many ways (though there are notable differences), so obtaining advice from them (or a similar company) could be useful. And who knows; they might learn a thing or two from us
OpenCraft’s hiring process is a bit intimidating, to be honest 
at most other companies, the interviewing process is longer and “harder” but, after that, you’re pretty much guaranteed to pass your trial period and stay as long as you like; at OpenCraft, the interviewing is short and it’s more aggressive in turning away candidates.
The idea of getting rejected just 2 months in scared me at first but I’ve gotten over that by framing it as a 2 month interview that I’m getting paid for; in the meantime, both OpenCraft and I get to know each other, without having to take each other’s word for it.
Something else to keep in mind is that timing plays a role here: if you’re rejecting an offer from another company to join OpenCraft, you’re probably not getting it back.
In summary, what I think is that most people still rate job security pretty high, despite the job market for developers being the best it ever was.
2 Likes
I have an external software development company with really great people that I know for sure could do a great job in a position like the ones we need here at OpenCraft. The company currently has availability and we could supply emergency developers for short, renewable periods of time, until the gap has been filled with direct hires.
I could compromise on making sure the work delivered is high quality, with minimal onboarding time, while also not reducing my commitment.
1 Like
Riffing off the bounty thing, would it be possible to create an “associate” role that sits between newcomer and core developer?
My hypothesis is that, since most people don’t pass their trial because they struggle with process, they could settle for a lower rate range and be freed from those responsibilities.
It would also sit nicely with bringing in contractors for short term work, as they’d simply get assigned tasks with well carved out budgets.
The obvious con here is that it increases planning burden on the core team (and I’m sure it has more holes someone else will point out 
)
1 Like
Same here-- @gabor we already have the handbook maintenance epic. Maybe we could fit this under there? Or would we need to create a new one, you think? If doing some or all of it under the handbook maintenance, we may need to adjust the budget to allow for the extra work.
I had my first two months which I passed close to a year ago, then I just had a contracting role until I decided to join core a couple of months back, during which I got a new two month trial period as I moved to BizDev and now I’m finally in core
There’s definitely a bit of awkwardness permissions-wise for contractors since they don’t get added to the core groups, however, if they’re around long enough they can end up in charge of epics and doing things normal newcomers don’t do. I’m not the first contractor to eventually switch over, which brings me to the next item…
I really like this idea, but there are only two things I’d like to bring up:
- We’d want to make sure this doesn’t introduce additional hierarchy into the organization. The flat, collaborative nature of this group is part of what makes it so awesome.
- It would be great if, should we come to really like those team members, there would be some way to bring them on board as core members eventually.
Maybe we could solve both 1 by having their contract require all disciplinary measures be performed by OpenCraft for the duration of the contract, and 2 by having a buy-out option. I’d suggest negotiating the terms of this ahead of time so that there isn’t extra tension down the line when trying to move them over, should we choose to do so.
We could handle it, but in that case – as you mentioned – we need a budget increase there. I would be good with that.
Let’s work that angle, then. The way I see it, the intro info that newcomers find needs to be well tied into the handbook anyway, so this is a good epic to organize the effort under.