Exit process proposal

International Governance
1

As discussed with the global team in Barcelona, and following the post from @sauloperez on core dev team pledge, I worked on a first proposal for an exit process.
We had worked on a onboarding process, with certification process (applied mainly for devs until now!) but we have not planned any process about how people can become “uncertified” or exit the core team (from certified regular contributor to become certified occasional contributor).

Here is the proposal: https://docs.google.com/document/d/1e9iFU9sH3SuIB2wcLctixEnTPwBVCE7zkKsq0WByOVc/edit?usp=sharing

This will be published here when it is ready, for now it is the same draft there.

Please comment and suggest modifications if you feel any need in the google doc! Thanks for your feedback :slight_smile:

@Kirsten @danielle @tschumilas @luisramos0 @enricostn @maikel @lin_d_hop @Hugs @oeoeaio @Rachel

2

@MyriamBoure I had a go at rewriting this, using your write up as the foundation, to try and make it a little clearer. There were lots of different concepts bunched in together, so I thought I’d have a go pulling them out into separate bits. Have a read (it’s below your version) and let me know if it’s ok xx

3

I love your rewrite @danielle :slight_smile: Just made some small suggestions, let’s discuss on the google doc :wink:

1 Like
4

I like it. For me, there is a lot of explanation of the reasons and then only one paragraph for the process and really one sentence for the decision: lazy consent. That is the most important part, but we don’t have any experience to base it on. I guess, over time we can flesh out that part with things like: “the member will be presented with reasons for the exit and has the opportunity to reply”. We don’t need to be that specific yet. Let’s see what feels right first and then document best practices.

Thank you for planning ahead! This is a great document to have when we come to it.

1 Like
5

the one thing that wasn’t clear to me as I read through was – who is this process applied to and when? Do ALL contributors (incl the core team) have a review - is it annually? - what prompts the review? 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? …

6

Hiya @tschumilas, responding to your thoughts above and also these ones from the google doc:

who is this process applied to and when?

and

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:

  1. 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.
  2. 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.
  3. 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!

1 Like
7

Yes, I understand how you feel @tschumilas and actually we openly discussed in Barcelona, and here on Discourse, the process to avoid creating any “dark back discussion”. But still we need to face the way we deal with tensions, as a mature community. I can talk about my personal experience of going through this with a dev we were paying in France, I was feeling he was not working the time he committed, he was not tracking his time, invoicing quite a lot compared to all other devs, he was taking 3 months to deliver on the thing that was supposed to be done in 2 weeks… and we were paying him! I discussed about it with him, tried different ways to ask him to track his time, etc. Then I felt powerless and asked the core team (very committed and daily engaged people who I know I can talk about those sensitive human issues) how they felt about that contributor, especially those who had worked with him, to check if that was only me! It took me 6 months to accept that we had to stop working with him, I wanted the OFN to be a way for him to learn and move forward, but his freedom and “not committing” will won. SO I share that experience as a concrete illustration of how it concretely happened, we need to have spaces to discussed in our small group of very daily committed people to handle such cases and find best ways 1- To help them go through the difficulties, and only if it doesn’t work 2- Manage exit with all the empathy and understanding we can…

1 Like
8

I totally agree with all of the above. My comments were not trying to generate overhead and extra time. They come from 2 decades of experience with performance management of a team of 120 people. having clear processes, that are communicated to eveyrone at the outset is key - and so I’m very happy we are working on this. BUT I still believe that its important that everyone who exchanges their time for something (money or other) should have the opportunity to improve, and receiving feedback is the best way for people to do this. So, I wonder - why wouldn’t we have a process where participants we consider the ‘core team’ (and honestly, I’m not sure who that is or how you get to be in that team), annually have a meeting where each person asks and receives open feedback from peers. maybe this happens informally now - but making it a bit more structured/formalized gives the team members time to prepare for both giving and receiving feedback. This was the place my comments were comming from - helping everyone continuously improve - not building bureaucracy.

the other part of this is that any individual paid by OFN has a legal employer/contractor. it could be OFN-CAN, or OFN-France or OFN-Aus… . While we work in a network, there is still a legal contract (even if only verbal) between the employer and employee, or contractor and contractee. So there are legal considerations and obligations for the OFN to be considered (ie: notice periods, severance requirements…). So we can write down our community process, but in the end, the legalities in the local situation could over-ride this anyway.

9

Yes, agree on legal aspect, but there is a commitment done when we recruit a paid contributor, where they commit to certain things, so if they don’t do it, we are also in our right to denounce the agreement somehow… that’s why making clear the “dev pledge” and having them sign it is important as well :slight_smile: it’s a symbol of commitment!
About organizing some peer feedback process, actually it happens I think informally as you say, and I don’t feel that we need to formalize it yet, but that will come probably when we develop, as we are now doing with exit process as we feel the need of it… or if people start to feel tensions about it. But it’s good to keep that in mind, and if we need to open some other discussion on it later on let’s do it. But let’s focus here on the specific process of “exit” and improve with small steps :wink:

10

Ok so the current version of the exit process is online here: https://ofn-user-guide.gitbook.io/ofn-contributor-guide/working-on-the-ofn-governance/team-organization/exit-process
I still need to add the link to the contributor pledge when it is published, still needs some adjustment.

11

Great document @MyriamBoure! I wonder about “Stepping back from Core Team to be an occasional contributor”. Is it really on purpose that we will still pay occasional contributions from certified devs? I don’t have a particular take on this, but wouldn’t that be unfair with other occasional contributors who aren’t certified?

I spotted a typo though. “contributor will changed to be an occasional contributor” should be “contributor will be changed to be an occasional contributor”.

12

I clarified the title @sauloperez to " Stepping back from Core Team to go back to certified occasional contributor". We do have occasional contributors who are not certified, and occasional contributors who are. The main difference between regular ('core team) and occasional certified people is time commitment . As if doesn’t have tech or com skills, will not remain certified at all.
But we can still question the “certified occasional contributors” status, but it will be on another thread, as it’s more about iterating on onboarding process and roles status then :wink: I think it’s good to keep it. Steve for instance is paid for his contributions, he works on specific and quick things we ask him to work on… If Rob would find some time some day and want to do some devs again on specific stuff prioritized by the community I guess we would be happy to give him some devs and pay him for it. So just to illustrate that certified occasional dev has still some sens IMO.

13

You convinced me with these examples :+1:

1 Like