More detailed paid time off policy

@pmachle1 reviewed our PTO policies, and noted that there was a gap between what is written in the handbook and what the law requires. See https://dev.gitlab.org/gitlab/organization/issues/367

With this merge request, we're creating a new page (https://about.gitlab.com/handbook/time-off) that holds the more detailed policies.

Additional edits need to be made to the Paid Time Off section of the main handbook in order to

• remove inconsistencies between the official full length policy and the short hand one
• link to the full length policies.

@sytses Let me know if you have any issues merging this request. I realize now that I built it from an old branch instead of from a fresh clone of the master. If you see merge conflicts, just deny the merge and I'll re-make from a clean version.

@ernstvn There is a lot of content but it is very fluffy, are people expected to read all this?

@pmachle1 Please review @sytses comments above.

Sytse, my understanding of these documents is that Paul wrote them (or had them written) to be consistent with federal, state, and even city law. Whenever you write a document that is so consistent with law and that can withstand legal scrutiny, it's going to be fluffy.

At a minimum it has to be consistent with our actual policy. Removing as much of the fluff as possible would also be nice, it is OK to have 20% of the risk left if we have something readable/changeable/actionable.

I agree that it needs to be consistent, but I think in this case the law is leading us to a change in policy rather than the other way around.

Regarding cutting fluff: I can take another look at it with the scalpel and see where I can remove words; but I won't remove information. Not sure how short I can make it.

So a mixed policy: without approval 4 weeks, with approval potentially more depending on circumstance? Or just the first part: 20 days off per year, no approval required.

?

I would say 20 days off, no approval req.

OK, that should be feasible. Let me check with @pmachle1 @slykahn and TriNet.

In general i made this so that tracking and reporting is not required. that is a huge win for us in terms of administration, financial reporting and cash flow. On the prior approval we certainly can make the document silent on that matter which is a better way to go than stating that employees can leave without approval.

Is there a way to do without tracking and without prior approval? I think people leaving for 100 days is something unlikely we can prevent in other ways (approval for more than x days).

yes, we dont need to track...i think prior approval is necessary (we can be silent on it as mentioned above)..but in general people do let their managers and others know when they are sick or on PTO - that is pretty standard.

also, we could change "approval" to "notification" if that makes it less cumbersome

Did I forget to mention I am taking 101 days off?

Added 1 commit:

• a6e39571 - Removed requirement for approval. Made general edits to cut length and fluff.

Added 1 commit:

• 358171e4 - Edited the non-exempt PTO policy to make it more succinct.

@pmachle1 and @sytses Please review the edits I made with the last two commits. Paul, let me know if you're having trouble pulling up a view that let's you read it effectively and see what I edited out.

One thing we do need to do is keep track of PTO when it is for being out sick. When I enter the date in TriNet, if the payroll period has already closed, the PTO will not show up in the payslip for the appropriate period. Ex. Phil was out sick on the 29th of this month. That period had aleady closed so I had to enter it in this pay period. He might be confused at some point if he reviews his payslip. We can create a sheet where we keep those dates. What do you all think of that?

Why is sick time so stringent compared to vacation. 3.3 hours per pay period is quite specific.

@dblessing , @pmachle1 can correct me if I'm wrong, but the Sick Time Off is a San Francisco city law that all HR organizations are struggling with to get in place and record properly etc. If it were up to me personally, there would not be such a strict limit on Sick Time... if you're sick you're sick after all.

@ernstvn I think you are correct. We will certainly not ding someone for being out sick like that. We will figure out how to document and treat our team with respect.

@slykahn Can you walk me through how this shows up on TriNet's records? Phil is an exempt employee, so it would not cut into his pay in any way. But you're saying that the TriNet payroll tracks the accrual and use of Sick Time Off? Does it have to be done through TriNet, or is it sufficient to have an administration in place of our own? I believe that the latter is the case (we can check with Leann as well on this), in which case we can be more flexible in how we handle the reporting.

As mentioned i dont think we need to formally track this at this point. our general policy should be that employees inform their managers when sick. (You dont need an approval to be sick!)

Thanks for explaining. That's an interesting law.

@sytses Please review and approve the MR.

This is not corresponding with what is in the handbook: "You do not need to ask for permission to take days off."

Whole paragraph can be replaced with: "Don’t frown on people taking time off, but rather encourage that people take care of themselves and others." which is stronger.

This is hard to parse, maybe easier to say that this applies to the vast majority and detail who is non-exempt. Exempt from what BTW?

Thanks for adding these links.

If this apply to both exempt and nonexempt, maybe move into separate section?

We don't have a scheduled start of the day.

You mean that if someone is sick or has a family emergency in their first week we won't give them time off? Where is the loyalty in that?

@ernstvn I stopped commenting before I was halfway. This document is not something that I can accept without major modifications. We expect our team members to be responsible and self organizing. This policy is everything but that, it is overly detailed and takes responsibility away from the team member. It goes against the letter and spirit of our existing policy. I recognize that we have to be compliant, but I'm sure there are less intrusive ways to do that. Let's discuss this in our next call.

I'd be happy to join the call to help. we can certainly make some modifications to reduce it in length and detail while making consistent with our policy and compliant with CA law.

@sytses and @pmachle1 I think we're going to have to sit down (virtually) and go through this together for the sake of efficiency. Paul, if you see easy ways to cut length and alter wording then please go ahead and do so. Otherwise, I will schedule a time in 2-3 weeks to discuss this.

@Ernst, Why don't you and I pull this document down into a google doc and go through it together with the intent to reduce and make more consistent with our guiding principles. Then we can sit down with Sytse and finalize. I don't think it's far from where we can agree it's an effective and administratable policy.

@pmachle1 That feels like going against the concept of using issues with comments etc. But I see the attraction: it would be great to see the comments when in editing mode.

Let's still do as you suggest in terms of going through it together, but let's not pull it out to a google doc, and then pull it back in... I'll send you a meeting invitation to tackle this together next week.

@ernstvn I think for efficiency it is better to have a call with the three of us in November (or discuss during the summit).

Closing this MR following discussion and creation of fresh MR: https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/1083

Status changed to closed