2 added 2 characters in body
source | link

I'm not sure you have to fire them entirely from the project, you could also move them to a position where they don't block other people (including you).

First, it sounds like the main problem for you is the coaching - so scale back the coaching. You could say something like:

Hey Bob, currently there's a lot going on in my life and I simply can't find the time for our training sessions [or whatever you call them] any longer, sorry about that.

Then, move them "out of the way" by assigning them one or two simple tasks with non-urgent priority. If they can learn and complete the task on their own: great, give them something more challenging and repeat until you've found their level of competency. If not, come back to them when the task has moved up in priority (when it's needed soon). If you want to be diplomatic about it, you could then say:

Hey Bob, we need the documentation / translations / tests executed / foobar soon. Could you take care of that and I'll take over on the defrobulator in the meantime?

It really helps if you can convince yourself that documentation and testing are important tasks - because they are. Many devs don't want to write documentation and that seals the fate of many a small open source software project: their software solves some problem but most people can't figure out how to use it, so nobody uses it.

Finally: you mention "I have never worked with other developers before" and it's not quite clear to me how you organise the work in your project. Organising software development is a very valuable skillset, so you may want to use this opportunity to learn and grow yourself. Learn to break work down into tasks and subtasks, to figure out dependencies, to estimate the time needed, to prioritse what is important and what can wait, to gauge who can do what. Learn how to best communicate with your fellow devs and how to replan when things don't work out the way you expected. Use the collaboration tools (issue tracker, versioning system, etc.). Maybe

Maybe methodologies en vogue in the business world at the moment (Scrum, Kanban, etc.) would give you some useful guidelines.

I'm not sure you have to fire them entirely from the project, you could also move them to a position where they don't block other people (including you).

First, it sounds like the main problem for you is the coaching - so scale back the coaching. You could say something like:

Hey Bob, currently there's a lot going on in my life and I simply can't find the time for our training sessions [or whatever you call them] any longer, sorry about that.

Then, move them "out of the way" by assigning them one or two simple tasks with non-urgent priority. If they can learn and complete the task on their own: great, give them something more challenging and repeat until you've found their level of competency. If not, come back to them when the task has moved up in priority (when it's needed soon). If you want to be diplomatic about it, you could then say:

Hey Bob, we need the documentation / translations / tests executed / foobar soon. Could you take care of that and I'll take over on the defrobulator in the meantime?

It really helps if you can convince yourself that documentation and testing are important tasks - because they are. Many devs don't want to write documentation and that seals the fate of many a small open source software project: their software solves some problem but most people can't figure out how to use it, so nobody uses it.

Finally: you mention "I have never worked with other developers before" and it's not quite clear to me how you organise the work in your project. Organising software development is a very valuable skillset, so you may want to use this opportunity to learn and grow yourself. Learn to break work down into tasks and subtasks, to figure out dependencies, to estimate the time needed, to prioritse what is important and what can wait, to gauge who can do what. Learn how to best communicate with your fellow devs and how to replan when things don't work out the way you expected. Use the collaboration tools (issue tracker, versioning system, etc.). Maybe methodologies en vogue in the business world at the moment (Scrum, Kanban, etc.) would give you some useful guidelines.

I'm not sure you have to fire them entirely from the project, you could also move them to a position where they don't block other people (including you).

First, it sounds like the main problem for you is the coaching - so scale back the coaching. You could say something like:

Hey Bob, currently there's a lot going on in my life and I simply can't find the time for our training sessions [or whatever you call them] any longer, sorry about that.

Then, move them "out of the way" by assigning them one or two simple tasks with non-urgent priority. If they can learn and complete the task on their own: great, give them something more challenging and repeat until you've found their level of competency. If not, come back to them when the task has moved up in priority (when it's needed soon). If you want to be diplomatic about it, you could then say:

Hey Bob, we need the documentation / translations / tests executed / foobar soon. Could you take care of that and I'll take over on the defrobulator in the meantime?

It really helps if you can convince yourself that documentation and testing are important tasks - because they are. Many devs don't want to write documentation and that seals the fate of many a small open source software project: their software solves some problem but most people can't figure out how to use it, so nobody uses it.

Finally: you mention "I have never worked with other developers before" and it's not quite clear to me how you organise the work in your project. Organising software development is a very valuable skillset, so you may want to use this opportunity to learn and grow yourself. Learn to break work down into tasks and subtasks, to figure out dependencies, to estimate the time needed, to prioritse what is important and what can wait, to gauge who can do what. Learn how to best communicate with your fellow devs and how to replan when things don't work out the way you expected. Use the collaboration tools (issue tracker, versioning system, etc.).

Maybe methodologies en vogue in the business world at the moment (Scrum, Kanban, etc.) would give you some useful guidelines.

1
source | link

I'm not sure you have to fire them entirely from the project, you could also move them to a position where they don't block other people (including you).

First, it sounds like the main problem for you is the coaching - so scale back the coaching. You could say something like:

Hey Bob, currently there's a lot going on in my life and I simply can't find the time for our training sessions [or whatever you call them] any longer, sorry about that.

Then, move them "out of the way" by assigning them one or two simple tasks with non-urgent priority. If they can learn and complete the task on their own: great, give them something more challenging and repeat until you've found their level of competency. If not, come back to them when the task has moved up in priority (when it's needed soon). If you want to be diplomatic about it, you could then say:

Hey Bob, we need the documentation / translations / tests executed / foobar soon. Could you take care of that and I'll take over on the defrobulator in the meantime?

It really helps if you can convince yourself that documentation and testing are important tasks - because they are. Many devs don't want to write documentation and that seals the fate of many a small open source software project: their software solves some problem but most people can't figure out how to use it, so nobody uses it.

Finally: you mention "I have never worked with other developers before" and it's not quite clear to me how you organise the work in your project. Organising software development is a very valuable skillset, so you may want to use this opportunity to learn and grow yourself. Learn to break work down into tasks and subtasks, to figure out dependencies, to estimate the time needed, to prioritse what is important and what can wait, to gauge who can do what. Learn how to best communicate with your fellow devs and how to replan when things don't work out the way you expected. Use the collaboration tools (issue tracker, versioning system, etc.). Maybe methodologies en vogue in the business world at the moment (Scrum, Kanban, etc.) would give you some useful guidelines.