Hiya @tschumilas, responding to your thoughts above and also these ones from the google doc:
who is this process applied to and when?
Maybe we need to be more clear stating who this process gets applied to and when?
This process currently applies to developers working on the global software project, as they are the only paid contributors that go through a certification process at this present moment in time. It is applied from the moment a developer is certified, as it is at this point in time that they commit to the pledge of minumum number of hours and to be a member of the team (with all that entails. @MyriamBoure perhaps a link to the pledge so people can see what devs commit to can be added here?)
what prompts the review?
This is where the process isn’t structured (at this moment in time). Through our experiences with developers who have come and gone it becomes obvious quite quickly when someone isn’t committing to the process we use and the way we work together. Usually this is evident to three different types of people within the project - other developers who are trying to code with them, the delivery train drivers who are trying to understand and manage what they’re building, and the person/s within the country that is managing that developer’s payments and involvement. The review is prompted when someone within these three groups triggers it, first by speaking to peers, and then trying to work with the developer in question to find out what’s going on and to try and work with them to improve the situation.
Is the review done in a dialogue fashion - or does the core team talk behind someone’s back and then relay a message to them?
A bit of both, I think. But it depends on whether you call a discussion, say between you and I, going behind their back, or a means of determining a path. Say, for example, you have a developer working in Canada who you feel isn’t truly committed to being a member of the team (e.g. a lone wolf developer who isn’t communicating effectively/frequently, and submits rather large invoices for work that according to other senior devs isn’t at a high quality). We speak about it, to sanity check what you’re feeling and determine an approach to sorting out the problem. We then follow through directly with that developer to try and improve their contribution…or if that doesn’t work then exiting them from the team.
Make sense? So it isn’t a “black box” kind of decision that they don’t have a part in, it’s more of a sanity check, with members of the team, to understand that the process of improvement needs to start.
This seems like a well thought out process, but it also gives ‘power’ to the core team. the risk is that an individual who has been exited may feel the core team had unrealistic expectations, or just didn’t like them, or whatever. So - is there a reason that we don’t have a process where all contributors (including the core team) have a regular performance review/discussion? … If it is a regularly scheduled process, applied to everyone, this minimizes the risk that someone feels they were singled out. Maybe that is the intention - to have this review done regularly on all contributors - but this wasn’t clear to me as I read this.
The reason I don’t agree with your through of regular reviews @tschumilas is three-fold:
- This creates overheads, process for the sake of a perceived concept of fair when most of the core paid developers continue to work well within the team and don’t require review.
- The people likely to do (or at least coordinate) the reviewing don’t currently get paid, ie. the train drivers. So it adds unpaid overhead to us, which I don’t think is an effective use of the time we donate to the project.
- This process has worked just fine up to this point, where we identify through our day to day work when someone isn’t living up to expectations and work with them to improve.
However, the reason I think a review system might be a good idea isn’t to do with the exit process so much as the developer skills levels we currently have in place (and pay a varied hourly rate accordingly), and determining when a developer is ready to step up to the next level.
So in terms of reviews, we’ll take it to the core team and figure out how/if they’re needed and would be incorporated into the process in a way that doesn’t create too much overhead.
Cheers for your feedback Theresa!