As GitLab continues to scale, our need for tools and automation to manage our growth expands along with it. To help the People Group, we have a People Group Engineering team, that consists out of People Group Fullstack Engineers to make our team more efficient and improve the effectiveness of our core People Group.
Responsibilities include (but are not limited to):
Quick navigation to some of our other pages.
Page | Description |
---|---|
Career Mobility | Our automation flow on how we streamile on processes. |
Employment Issues | Information regarding our onboarding and offboarding issue automations. |
GH <=> BHR Sync | Our automation for syncing Greenhouse candidates to our HRIS system. |
Nominator Bot | Information regarding our custom Slack app, how to use it, FAQ's, and engineer guides. |
Offboarding | Our offboarding automation flow and everything you may need to know regarding this. |
Onboarding | Our onboarding automation flow and everything you may need to know regarding this. |
People Connect Bot | Information regarding our custom Slack app for our Service Desk integration. |
Internal Handbook | Our People Group Engineering internal handbook. |
Slack Integrations | Information on some of our slack integrations like birthday announcments, PTO, etc. |
Miscellaneous | Some extra information regarding PTO, sensitive data, accruals, and more. |
If you'd like to request engineering assistance with an issue, bug fixes, urgent requests related to People Group processes
or tools (like BambooHR) or anything relating to People Group Engineering, please start by
creating an issue
in the People Group Engineering project. All issues are reviewed and prioritised to a specific team through our kanban board. If you require general support with MR's, kindly collaborate with all of GitLab team members in #mr-buddies
in slack.
If you are looking for help regarding general inquiries such as: payroll, paid time off, benefits, etc. Please reach out to our People Connect team in their slack channel, #people-connect
.
If you want to report bugs about existing integrations, you can use any of the following templates:
We have monitoring setup in case some of our applications are no longer accessible. This is the case for all of our integrations. This will trigger notifications to the People Group Engineer(s). If you need our immediate attention, feel free to use our #peopleops-eng
Slack channel. Avoid pinging people directly unless there is a real urgency to the matter.
The People Group Engineering board
serves as the single source of truth on the engineering team's priorities. Issues follow a linear sequence, with a Workflow::
label indicating an issue's current status:
Workflow::Triage
: Issues start here. Issues in triage must be further defined before they're able to
be made ready for development. Once the problem and a proposal for solving it is defined to the point where an
engineer can begin work, it can be moved to Workflow::Ready for Development
.Workflow::Ready for Development
: Issues that are groomed and are ready for an engineer to begin work. They're
well defined in terms of the problem, and have a proposal that's defined enough for us to begin work; not every detail
needs to have been defined, but an engineer should be able to start work on this issue by reading the issue description alone.Workflow::Next Up
: These issues are determined as the next ones that we should work on. We try to keep this list to about 4 / engineer
in the team.Workflow::In Progress
: Issues that are actively being worked on by a developer.Workflow::Verification
: Issues that have engineering work complete and ready for evaluation. At this point, the developed solution
should be evaluated (by the issue reporter or another stakeholder) to verify that it solves the original problem.Workflow::Complete
: Once signed off, the issue should be closed and Workflow::Complete
should be applied to signal
the work is verified and complete.There are three more states an issue can be placed in:
Workflow::Waiting
: Issues that are waiting from input from someone or are waiting on a dependency. These are
issues that need input or progress from others before they can progress.Workflow::Blocked
: These issues are either blocked by another issue or by missing API endpoints. The People
Ops Engineer always adds the reason why an issue is moved to blocked.Workflow::On Hold
: These issues are currently on hold and the requester has been informed about this. It is still an important idea but there may not be capacity or resources to move the request forward. When a change in capacity and/or resources happens, we will re-evaluate the status of the ticket.We have a performance indicator set to having new tickets being triaged within 7 working days. Everyone in the People Engineering team can triage new tickets. What we do when a new ticket comes in:
Workflow::Waiting
Workflow::Waiting
~p-compensation-calculator
, ~p-employment-automation
, etc)PopsEng::Team::Tech
, PopsEng::Team::Engineering
, etc). You can also find a GitLab board, with the issues sorted by team here.~PopsEng::New Project
or a bug ~PopsEng::Bug
or an addition to an existing project or integration ~PopsEng::Addition
Workflow::Ready for Development
or Workflow::Next Up
Note: for bugs, we have another performance indicator that requires us to take action within one working day. This is because often a bug in any of the integrations would lead to inefficiences and manual work for the People Group.
Before we state a ticket as fully triaged, we need to have the following information:
With that knowledge in mind we determine the priority of a ticket, with the following table:
Priority Level | Compliance | Impact | Occurrence | Project involved |
---|---|---|---|---|
p1 (~PopsEng::Priority::1 ) |
yes | Any | daily, weekly or monthly | n/a |
p1 (~PopsEng::Priority::1 ) |
no | OKR progression | n/a | n/a |
p2 (~PopsEng::Priority::2 ) |
no | Company | daily, weekly | comp calc, nom bot, or conservatory |
p3 (~PopsEng::Priority::3 ) |
no | Division, Department or Team | daily, weekly | nom bot or conservatory |
p4 (~PopsEng::Priority::4 ) |
no | Any | daily, weekly | n/a |
p5 (~PopsEng::Priority::5 ) |
no | Any | monthly, yearly | n/a |
Our issues will be labeled according to the priority level. Anything that falls outside of the table won't be labeled with a priority and will be added to our backlog and worked after priority items are completed. As this is a first iteration, we will review those without labels to see if they should've been labeled differently and if we need to rework this table.
Currently we moved away from monthly milestone and are trying out a Kanban approach for our work. The board
can be found here. The column
Workflow::Next Up
is the one that determines our next work.
The People Engineering team, tries to keep that column at about 4 tickets / engineer, so it's clear what our next priorities are. To determine what gets moved into that column, we use our priority labels. However there are two exceptions on the priority labels:
bug
: these are tickets that often need to be fixed asap as this is usual an existing project or integration that is brokencode maintenance
: these are tickets like library updates or refactors that we need to plan in to make sure our code stays up to standards and secureWe've build several automations and tools to support our People Group. In the following pages, you can find more details about all the different projects or automations we've created:
For all automations we use 2 main sources:
If any other sources are used for a specific integration or automation, it is mentioned on the section.
When a project uses API tokens with a certain level of access, we mirror the public project to a private project on ops.gitlab.net. These projects are only used to execute the scheduled jobs. For all planning, coding and collaboration we use the public projects.
Before the PeopleOps team member can excute the chat commands mentioned on this page, they need to be invited to the employment-automation project. This can be done by the owners of the project.
Once you are a member of the project, you can run any /pops
command. The PeopleOps bot will respond that you
first have to connect your GitLab account. You can click the provided URL and authorize. Now you are able to run
the /pops
commands.