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):
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 milestone. If you require general support with MR's, kindly collaborate with all of GitLab team members in #mr-buddies in slack.
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 the compensation calculator and the assessment tool. This will trigger text messages 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
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::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.
There are two 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.
We plan everything in monthly milestones. Every new milestone, starts at the beginning of the month. The first day of the milestone, someone in the People Engineering team will post a summary of the past milestone in #people-group on Slack. This should contain the main items we've worked on. If important issues weren't finished, this is also the place to communicate this. In the same summary, we also add the big next month tickets and paste a URL to the board with the milestone.
At the start of the milestone, all tickets we aim to finish within the milestone should be labeled with the
label. That way we can easily see the difference between scheduled vs unplanned work. If a
Deliverable ticket can't be
wrapped up during the milestone, we should communicate this as soon as possible to the stakeholders.
We'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