We are having difficulties with capacity. How do we address this?

This is an interesting idea. Maybe we could have Fixate design something for this? We could rename the ‘Jobs’ page ‘Join Our Team’ and have a sort of overview of the company from a member’s side with nice graphics, and then links to the current postings.

This is a good idea. I think it may help us in the long term. If they are highly specialized, though, it may take us some time to find one. Would we be able to start the search for this specialist and in the meantime contract a more generic headhunting service? @usman, @paulo (and @sid, when you come back) would you be willing to create a ticket to start on next steps for a headhunter/O.D. hiring, if these sound good to you?

Does anybody share the feeling that we’re the experts? Which is to say:

  1. I doubt we’ll find a person that can pull solutions to our highly specialized problems out of a hat. Yes, there are larger remote, open source companies (Canonical, maybe some divisions of Redhat), but none I’ve ever heard of with OpenCraft’s particular blueprint. I’d go as far as saying that in some respects we’re more like Debian than a for-profit company (which is a good thing!).

  2. Once we solve this phase of our growth, I think OpenCraft can start selling O.D. consultancy for this particular niche. (Dead serious: I consider doing it myself, from time to time.) Doing remote right is hard. Doing open source right is hard. Doing it all and making a profit, while being “open first” no less, is even harder.

Which is not to say that we don’t need somebody to sit down and think about the problem and try to find solutions. It’s just that maybe that(those) person(s) should be from our own team… once we have capacity, of course. ;)

PS: Re-reading this, I imagine it can sound like I’m volunteering. I’m not. There are many core members that have been here much longer and are much, much better at OpenCrafting than I am. Pretty much still have my training wheels on.

2 Likes

Now that I’ve had a chance to read closer on the O.D. Wikipedia entry, I have noted how strikingly similar it is to the work we’ve already been doing. I know I’ve actively engaged in many of the activities listed and didn’t even know there was a name for it.

This would probably go with our push to open up the other side of the business alongside the process manager-- since as we’ve discussed previously we want to be able to expand to market and sell consulting and software around our async processes. So yes, that’s a great idea long term-- finding a way to promote from within an O.D. specialist.

2 Likes

That’s a pretty big caveat… luck and timing will play a huge role in getting us through here, so success doesn’t automatically qualify us to bottle our approach and sell it.

But you’re totally right: doing all of this is hard. And the sheer number of hats we all wear, each day, is part of why hiring the right people is so difficult to do. I wouldn’t propose to add yet another hat by adding O.D to our consulting services. But I do think blogging about it would help other organisations like ours.

While I’m totally in favor of requiring previous open-source work for candidates, I think it could be a big barrier to entry for many who would otherwise be good candidates; in my case, most if not all of my contributions were done as part of my job but they only happened because I took the liberty of doing so, some times while omitting the fact to my employer :blush: .

One of the ways in which we could lower this barrier could be introducing bug bounties.

Pros:

  • candidates without previous open-source contributions can get paid for their work to meet that requirement;
  • might put some candidates that wouldn’t otherwise apply (for whatever reason) on our radar;
  • allows us to offload small but perhaps important pieces of work.

Cons:

  • extra work to maintain the list of open bounties (but not too much hopefully).

I think this is a very good idea. We have already been discussing adding a step in the interview process where candidates would be paid to submit (and merge) just such a type of issue. But the problem with the during-the-interview approach would be that we’d have to give each candidate their own bug.

If, on the other hand, we have a list of open bounties and some people work on them simultaneously, whoever gets the fix merged first gets paid. :man_shrugging:

I’m not sure we’d want to restrict the pool of candidates to those that got bounties, though. But maybe we could do both simultaneously, until a time when the bounty list is popular enough to generate enough candidates for our hiring needs.

(Cross reference to the help mailing list)

This was a really poor choice of words :scream: what I meant, of course, was that I didn’t think it was necessary to ask for permission and went ahead; by contrast, I’m pretty sure many developers don’t work in an environment where that’s possible.

It’s worth noting that we used to do this. It was part of my interview process-- I’m not sure if we had the extended trial period then, or if this was the last step. An Open edX bug was selected, and then the candidate was to fix and submit the bug. They were paid for the hours, but the biggest problem with this approach was the amount of time it took. It was highly dependent on when Open edX would review a bug.

However… Now we have core committers. So if we made the bugs be within an area where Open Craft has Core Committer access, this might not be as much of an issue anymore.

Would we want to do this for all candidates or just for those for whom we had little to no evidence of open source contribution?

What @joao.cabrita suggested and I seconded was the other way around: we pay a pre-determined sum for merged bounties, and then we interview/trial from the pool of successful bounty-hunters.

1 Like

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?

5 posts were split to a new topic: Capacity Discussion - Reallocation

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