Commit 586e911c authored by Sean McGivern's avatar Sean McGivern

Merge remote-tracking branch 'origin/master' into am-sop-update

parents a62ba518 8baa1a76
Pipeline #5237157 passed with stages
in 11 minutes and 37 seconds
- country: United States
employee_factor: 1
- country: Netherlands
- country: Belgium
employee_factor: 0.8
- country: India
employee_factor: 0.6
- country: Netherlands
employee_factor: 0.8
- country: United Kingdom
employee_factor: 0.9
employee_factor: 0.85
- country: United States
employee_factor: 1
- country: '*'
contractor_factor: 1.17
\ No newline at end of file
contractor_factor: 1.17
......@@ -67,6 +67,7 @@
- title: "Frontend Engineer"
description: /jobs/frontend-engineer/
salary: 83132
apply: https://gitlab.workable.com/jobs/181461/candidates/new
open: true
......@@ -87,6 +88,7 @@
- title: "Production Engineer"
description: /jobs/production-engineer/
salary: 110295
apply: https://gitlab.workable.com/jobs/142989/candidates/new
open: true
......@@ -124,6 +126,7 @@
- title: "UX Designer"
description: /jobs/ux-designer/
salary: 85843
apply:
open: false
......@@ -154,5 +157,5 @@
- title: "VP of Marketing"
description: /jobs/vp-of-marketing/
apply:
apply:
open: false
text: "New Survey Reveals 92% of Developers Prefer Git. Read the report."
link: /2016/11/02/global-developer-survey-2016/
text: "Join us for our next webcast, Monitoring Distributed Systems with Prometheus, on December 14."
link: https://page.gitlab.com/20161207_PrometheusWebcast_LandingPage.html
......@@ -1096,9 +1096,9 @@
Luke believes that Git is one of the most significant tools in today's digital toolbox. After recognising the importance of the GitLab vision and values, he couldn't have got on board any quicker. Luke is excited to use Ruby, JavaScript and Sass to craft rich and elegant user experiences at GitLab. In his spare time, Luke enjoys cooking, pretending to understand financial markets and hacking intelligence into boring household applicances.
- name: Brittany Rohde
locality: Tacoma, WA
locality: Columbus, GA
country: USA
role: <a href="https://about.gitlab.com/jobs/people-ops-coordinator/">People Operations Coordinator</a>
role: <a href="https://about.gitlab.com/jobs/people-ops-specialist/">People Operations Specialist</a>
reports_to: Senior Director of People Operations
picture: brittanyrohde.jpg
twitter: brittany_rohde
......@@ -2045,16 +2045,16 @@
story: |
Joining November 28th
- name: H.K.
locality:
country:
- name: Harish Ramachandran
locality: Jacksonville, FL
country: USA
role: <a href="https://about.gitlab.com/jobs/service-engineer/">Service Engineer</a>
reports_to: Support Lead
picture: logo-extra-whitespace.png
twitter:
gitlab:
picture: harish-ramachandran.jpg
twitter: harishsr
gitlab: harish
story: |
Joining November 28th
Ever since Harish rediscovered his childhood joy of programming, he has spent most of his time either on the computer writing code or learning new ways to code. He loves spending the rest of his time with his lovely wife and two kids, or hanging out with friends in Jacksonville, Florida. He also enjoys exercising and you will usually find him beginning each day with a trip to the gym.
- name: T.A.
locality:
......
......@@ -83,6 +83,8 @@ extra_js:
%b APPS
%a.image-link{href: "/images/feature_page/screenshots/09-review-apps.png"}
= image_tag "/images/feature_page/screenshots/09-review-apps.png", class: "img-responsive"
.link
%a{href: "https://about.gitlab.com/features/review-apps/"} Read more on Review Apps
.col-md-4.small-feature
.name
CONTAINER
......
......@@ -194,7 +194,7 @@ This info is needed to get your profile ready with Savvy HR in order to get you
1. [ ] Hiring Manager: Open a new [support onboarding boot camp issue](https://gitlab.com/gitlab-com/support/issues) using the support [onboarding checklist](https://about.gitlab.com/handbook/support/onboarding/checklist), and provide the link in a comment below this onboarding checklist.
1. [ ] Hiring Manager: Provide access to hackerone.com
1. [ ] Zendesk:
1. [ ] Hiring Manager: [Add new team member](https://support.zendesk.com/hc/en-us/articles/203661986-Adding-end-users-agents-and-administrators#topic_h43_2k2_yg) as an agent in [GitLab ZenDesk](https://gitlab.zendesk.com); you may need to [purchase a new license](https://about.gitlab.com/handbook/support/knowledge-base/categories/zendesk/#adding--removing-agents-in-zendesk)
1. [ ] Hiring Manager: [Add new team member](https://support.zendesk.com/hc/en-us/articles/203661986-Adding-end-users-agents-and-administrators#topic_h43_2k2_yg) as an agent in [GitLab ZenDesk](https://gitlab.zendesk.com); you may need to [purchase a new license](https://about.gitlab.com/handbook/support/knowledge-base/zendesk/#adding--removing-agents-in-zendesk)
1. [ ] Hiring Manager: Add agent to required [support groups](https://support.zendesk.com/hc/en-us/articles/203661766-About-organizations-and-groups) in [GitLab ZenDesk](https://gitlab.zendesk.com).
1. [ ] Community Forum:
1. [ ] New team member: Create new account for the [GitLab community forum](https://forum.gitlab.com/) using the sign in with GitLab option and mention the username used.
......@@ -206,7 +206,7 @@ This info is needed to get your profile ready with Savvy HR in order to get you
1. [ ] Hiring Manager: Open a new [support onboarding boot camp issue](https://gitlab.com/gitlab-com/support/issues) using the support [onboarding checklist](https://about.gitlab.com/handbook/support/onboarding/checklist), and provide the link in a comment below this onboarding checklist.
1. [ ] Zendesk:
1. [ ] Hiring Manager: [Add new team member](https://support.zendesk.com/hc/en-us/articles/203661986-Adding-end-users-agents-and-administrators#topic_h43_2k2_yg) as an agent in [GitLab ZenDesk](https://gitlab.zendesk.com); you may need to [purchase a new license](https://about.gitlab.com/handbook/support/knowledge-base/categories/zendesk/zendesk_tips.html#adding--removing-agents-in-zendesk)
1. [ ] Hiring Manager: [Add new team member](https://support.zendesk.com/hc/en-us/articles/203661986-Adding-end-users-agents-and-administrators#topic_h43_2k2_yg) as an agent in [GitLab ZenDesk](https://gitlab.zendesk.com); you may need to [purchase a new license](https://about.gitlab.com/handbook/support/knowledge-base/zendesk/zendesk_tips.html#adding--removing-agents-in-zendesk)
1. [ ] Hiring Manager: Add agent to required [support groups](https://support.zendesk.com/hc/en-us/articles/203661766-About-organizations-and-groups) in [GitLab ZenDesk](https://gitlab.zendesk.com).
1. [ ] Community Forum:
1. [ ] New team member: Create new account for the [GitLab community forum](https://forum.gitlab.com/) using the sign in with GitLab option and mention the username used.
......
......@@ -54,6 +54,12 @@ When your post gets published, send us an invoice. GitLab will pay you in
American Dollars (USD) from a bank account in the USA, via wired transfer
to your bank account.
## Notes
- If you want to write about your own product (or the product you represent), and how it integrates with GitLab, we'll be happy to have you as a [Guest Writer](../#guest-posts). The Community Writers Program won't apply for these cases.
- You are encouraged to write more than one post. If you succeed on the first process, we'll be glad to have you writing for us regularly. The process for writing more than one post is exactly the same for writing the first one. Please, pick up an issue at a time.
- Your post must be original, comprehensible, technical, and unprecedented.
## Learn More
- [Publishing Process for Community Writers][publishing-process]
......
......@@ -320,12 +320,6 @@ Who should I connect with for my 10 1:1 onboarding calls?
[Additional FAQ's](https://docs.google.com/a/gitlab.com/document/d/1O_DTqnsQaHpqFeA7h24R-ozu0ZeyHey0yNI0GIAA7_w/edit?usp=sharing)
#### Improvements/Contributing<a name="contribute"></a>
- If you get an answer to a question someone else may benefit from, incorporate it into this handbook or add it to the [FAQ document](https://docs.google.com/a/gitlab.com/document/d/1O_DTqnsQaHpqFeA7h24R-ozu0ZeyHey0yNI0GIAA7_w/edit?usp=sharing)
- After meetings or process changes, feel free to update this handbook, and submit a merge request
- Create issues for any idea (small or large that), that you want feedback on
#### Variable Compensation Guidelines<a name="compensation"></a>
Full-time BDRs have a significant portion of their pay based on performance and objective attainment. Performance based "bonuses" are based on results. Actions for obtaining results will be prescribed and measured, but are intentionally left out of bonus attainment calculations to encourage experimentation. BDRs will naturally be drawn to activities that have the highest yield, but freedom to choose their own daily activities will allow new, higher yield activities to be discovered.
......@@ -338,25 +332,11 @@ Guidelines for bonuses:
- E.g. a new BDR's first month's bonus is typically based on completing [onboarding](https://about.gitlab.com/handbook/general-onboarding/)
- Bonuses may be tied to sales target attainment, [OKRs](https://about.gitlab.com/handbook/marketing/#okrs), or other objectives.
#### BDR Vacation Incentives<a name="vacation"></a>
Note: this is a new, experimental policy started in June 2016: changes and adjustments are expected
At GitLab, we have an [unlimited time off policy](https://about.gitlab.com/handbook/#paid-time-off). The business development team has additional incentives for taking time off:
- The first 5 business days taken off by a BDR in a calendar year prorates their target by 100%, rounded up (i.e. reduces the BDR's target by the period's target divided by the number of business days in the period, times the number of days taken off).
- The second 5 business days are prorated by 50%, rounded up if applicable
- The third 5 business days are prorated by 25%, rounded up if applicable
- Example: A BDR with a target of 200 opportunities in a January with 20 business days can reduce that month's target to 190 by taking 1 day off, 150 by taking 5 days off, 125 by taking 10 days off, or 113 by taking 15 days off.
Rules and qualifications for BDR Vacation Incentives:
- BDRs must give notice 30 days ahead of intended time off to by the Team Lead and Senior Demand Generation Manager (and ensure they acknowledge receipt within 48 hours)
- BDRs must add intended time off to the availability calendar
- Prorated days can be deferred (i.e. take PTO without prorating the target), but are lost at the end of the year. Incidentally, the math usually works out in favor of not deferring.
- BDRs can take additional vacation days (see [GitLab PTO policy](https://about.gitlab.com/handbook/#paid-time-off), but time off beyond 15 days will not adjust targets.
#### Improvements/Contributing<a name="contribute"></a>
With [GitLab's PTO policy](https://about.gitlab.com/handbook/#paid-time-off), there's no need to give notice or ask permission to take time off. Unfortunately, a quota carrying BDR can expect to lose some earning potential for taking PTO, which often leads to BDRs not taking vacation. Another problem with unlimited PTO is that management loses forecasting power when BDRs take unexpected PTO, making it tempting for leadership to discourage vacation. We hope that this additional vacation incentive for the team acts as a balancing incentive to both parties by (a) providing a prorated quota for BDRs who plan ahead and (b) helping leadership plan and forecast better without discouraging vacation.
- If you get an answer to a question someone else may benefit from, incorporate it into this handbook or add it to the [FAQ document](https://docs.google.com/a/gitlab.com/document/d/1O_DTqnsQaHpqFeA7h24R-ozu0ZeyHey0yNI0GIAA7_w/edit?usp=sharing)
- After meetings or process changes, feel free to update this handbook, and submit a merge request
- Create issues for any idea (small or large that), that you want feedback on
#### Additional Resources
......
......@@ -137,4 +137,4 @@ Respond to questions about GitLab on Quora, especially the ones that appear in t
## Relevant Links
- [Social Media Guidelines](/handbook/marketing/social-media-guidelines/)
- [Support handbook](/handbook/support), with specific link to how to work in [Zendesk (for Twitter)](/handbook/support/knowledge-base/categories/zendesk/).
- [Support handbook](/handbook/support), with specific link to how to work in [Zendesk (for Twitter)](/handbook/support/knowledge-base/zendesk/).
......@@ -41,6 +41,8 @@ where:
- `Experience Factor` falls between 80% - 120%
- `Contract Type Factor` distinguishes between employee or contractor, and can be a different factor in each country; see below for further explanation. The full list of contract type factors is stored in the [`contract_types.yml` file](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/contract_types.yml).
See the calculator in action for example for the Developer role, on the Developer [job description](https://about.gitlab.com/jobs/developer/).
### How was it developed?
In developing the compensation formula above, we looked at the compensation of our
......
---
layout: markdown_page
title: "Data analysis"
---
### Get a GitLab Linux account
Ask production folks (`#infrastructure` channel) to set up a Linux account for you. Mine is `victor`, and is used as an example below.
### Access `worker1.staging.gitlab.com` staging rails console
Access the server
```
$ ssh victor@worker1.staging.gitlab.com
```
Run
```
$ sudo gitlab-rails c production
```
### Access `db2.staging.gitlab.com` db
As required, ask production folks to refresh the `db2.staging.gitlab.com` db with the `gitlab.com` db.
Access the server
```
$ ssh victor@db2.staging.gitlab.com
```
Run
```
$ sudo gitlab-psql gitlabhq_production
```
### Access `version.gitlab.com` db
Access the server
```
$ ssh victor@version.gitlab.com
```
Use `psql`
```
$ sudo su postgres
$ psql
```
Access the db
```
postgres=# \c version_gitlab_com_production
postgres=# \dt
```
### Access db from a sql client
Access db from a sql client for additional features and ease of use. The sql client can connect to your local machine, and tunnel to the server. A suggested native Mac sql client is [Postico](https://eggerapps.at/postico/). Ask GitLab to expense a license. Download and install.
Set up forwarding through your local machine by running one of the following
```
$ ssh -L5432:localhost:5432 victor@db2.staging.gitlab.com
$ ssh -L5432:localhost:5432 victor@version.gitlab.com
```
#### `db2.staging.gitlab.com`
Find the database password on `db2.staging.gitlab.com`
```
$ vi /etc/gitlab/gitlab.rb
```
Look at `postgresql['sql_password']`.
In your sql client, connect with
```
host: localhost
port: 5432
username: gitlab
password: <password>
database: gitlabhq_production
```
#### `version.gitlab.com`
Find the database login and password on `version.gitlab.com`
```
$ sudo cat /home/gitlab-version/version-gitlab-com/config/database.yml
```
In your sql client, connect with
```
host: localhost
port: 5432
username: gitlab-version
password: <password>
database: version_gitlab_com_production
```
---
layout: markdown_page
title: "Product Areas"
title: "Product areas"
---
GitLab is one integrated product. But to facilitate communication and collaboration, we loosely categorize GitLab into these areas.
## Discussion
## GitLab Discussion (GD)
### Features
GitLab Discussion (GD) is focused on the collaboration features of GitLab, with major areas including:
GitLab Discussion (GD)'s _main areas_ are:
* Code review, merge requests, and approvals
* Groups
* Groups and projects
* Snippets and wikis
* Issues
* Labels and milestones
* Issue boards
* Labels
* Milestones
* Projects
* Snippets
* Wikis
GD does _not_ focus on these areas:
GD is _less concerned_ about:
* CI/CD
* Cycle analytics
* GitLab integration (third-party services)
### Current product development focus
These are the 4 major areas of current focus for product development in GD.
#### _Team collaboration with issue boards_
There is a huge opportunity for GitLab to **move into and disrupt** the space of entrenched competitors in the "project management" space. We have the strategic benefit of being one coherent platform, allowing typical "project management" features to seamlessly flow into the more technical software phases of work. Our focus is to leverage the concept of issue boards to solve many of these team collaboration problems.
#### _Merge request workflows_
Organizations may have very specific policies on how software is created, in the areas of code review, testing, and sign-off. In particular, merge request approvals, blocking, and associated workflows require powerful features. GitLab is lacking in these areas. In order to **compete** in this area, we are focused on enhancing merge request workflows.
#### _Issue view_
We are continually making improvements to GitLab in terms of **usability** to help people get their work done, and do it well in a collaborative team. In particular, we are focused on the issue view to establish a baseline of **user experience to achieve collaboration** in a single page, so that we can quickly get feedback from a coherent experience. This will inform our designs as we carry them over to other areas of GitLab.
#### _Code review beyond merge request workflows_
Code review happens beyond evaluating diffs inside a merge request. People want a light weight mechanism to browse through code, collaborating with other folks, without incurring the heavy burden of branches, commits, and merge requests. This is not an active area being pursued by major competitors. But it is a space of ongoing innovation. We want to take these **high risk high reward** bets, and invent some awesome new tools to delight our users.
### Prioritization
If a new issue comes in, then we should evaluate its priority according to:
1. Is the new issue a major regression or bug? Is it something that we need to ship for a customer immediately to address a major concern? If yes, prioritize it.
1. Does this new issue fit into our current product focus (for GitLab Discussion)? If yes, where does it belong in priority with our ongoing features?
1. If it doesn't fit into our product focus, but is obviously super important, let's revisit our product focus.
1. If it doesn't fit into our product focus, and it's not super important, then de-prioritize it. We will not spend resources on it now.
### Scenarios
Product Managers, Project Managers, Business Analysts, and Engineering Managers figure out what needs to be built based on investigation and analysis, which they do themselves and/or work with colleagues on.
They translate these concepts into something one level more concrete.
Product Managers, Project Managers, Business Analysts, and Engineering Managers figure out what needs to be built based on investigation and analysis, which they do themselves and/or work with colleagues on.
They translate these concepts into something one level more concrete.
This is where GD begins.
GD provides the tools to enable these folks to document and collaborate on those concrete ideas.
......@@ -36,11 +55,11 @@ These include issues, commenting, prioritization, and organization features.
UX Designers, Visual Designers, Software Engineers, Test Engineers, and Database Engineers create the product in a more tangible form.
GD allows these folks to collaborate with each other.
This creation is from ideation to shipping the product.
Branching, merge requests, and code review are the main features supporting collaboration.
This creation is from ideation to shipping the product.
Branching, merge requests, and code review are the main features supporting collaboration.
The existing features are focused on the git system and the concept of source control.
The first wave of innovation is making these easier so that engineers don't need to be git experts and they can get a lot done in a browser context.
The next innovation is to jump out of the git paradigm and abstract away from commits and branching.
The next innovation is to jump out of the git paradigm and abstract away from commits and branching.
GD allows all these folks to zoom out and look at the big picture, and zoom back in to focus in on tiny details, depending on the scenario.
We are working to strengthen this zoom in and zoom out dynamic, with milestones and boards being the early stages of this innovation.
\ No newline at end of file
We are working to strengthen this zoom in and zoom out dynamic, with milestones and boards being the early stages of this innovation.
......@@ -242,10 +242,10 @@ Here is also a list of resources that you may find useful to include on your lan
- [What is GitLab](https://about.gitlab.com)
- [What is GitLab EE](https://about.gitlab.com/features/#enterprise)
- [CE vs EE comparison](https://about.gitlab.com/features/#compare)
- [CE vs EE comparison](https://about.gitlab.com/products/#compare-options)
- [GitLab CI](https://about.gitlab.com/gitlab-ci/)
- [GitLab Geo](http://docs.gitlab.com/ee/gitlab-geo/README.html)
- [Pricing](https://about.gitlab.com/pricing/)
- [GitLab Geo](https://about.gitlab.com/features/gitlab-geo/)
- [Pricing](https://about.gitlab.com/products/)
- [GitLab Blog](https://about.gitlab.com/blog/)
- [GitLab Culture](https://about.gitlab.com/culture/)
- [Gitlab on Twitter](https://twitter.com/gitlab)
......
......@@ -146,7 +146,7 @@ Applying any of these macros will move the ticket to the tier group selected.
### Zendesk SLA settings and Breach alerts
SLAs are set as Business Rules within Zendesk. For more information, please refer to the specific [Zendesk](/handbook/support/knowledge-base/categories/zendesk/zendesk_tips.html) page.
SLAs are set as Business Rules within Zendesk. For more information, please refer to the specific [Zendesk](/handbook/support/knowledge-base/zendesk/zendesk_tips.html) page.
## How we're doing
......@@ -242,7 +242,7 @@ We offer "implementation support" for new EE customers. This is similar to live
Customers who purchased Premium Support have access to a Dedicated Service Engineer. This means that tickets that arrive in Zendesk from people within the subscriber's organization are routed to a dedicated SE by way of a trigger in Zendesk.
- The sales team requests a Dedicated Service Engineer (DSE) by creating a confidential issue on the [support issue tracker](https://gitlab.com/gitlab-com/support/issues/new), using the ["Dedicated Service Engineer" issue template](https://gitlab.com/gitlab-com/support/raw/master/.gitlab/issue_templates/Dedicated%20service%20engineer.md) (available as a template upon creating a new issue in the Support issue tracker) as soon as it is clear that a dedicated service engineer will be needed (this can be _before_ the deal is closed). The issue should be assigned to the Support Lead. Please include details that are requested in the template such as client timezone, language, specific needs, etc. to make it easier to assign an appropriate SE to the account.
- Once agreement is reached on who the DSE should be, following a workflow that is similar to how people are added to email forwarding aliases, or vaults in 1Password, in the [Dedicated Service Engineers google doc](https://docs.google.com/spreadsheets/d/1fCQ3yTbu6y2uKMM4IIEljzAZgHX2FFeG2y9XwWy7G-g/edit#gid=0), write in the customer name and chosen DSE using the "suggesting" mode. Any of the Service Engineers with admin access in Zendesk can then [create the trigger](/handbook/support/knowledge-base/categories/zendesk/create_dse_trigger.html), and "accept" the suggestion. Having the google sheet allows for greater visibility within the organization since not everyone knows their way around Zendesk or SalesForce.
- Once agreement is reached on who the DSE should be, following a workflow that is similar to how people are added to email forwarding aliases, or vaults in 1Password, in the [Dedicated Service Engineers google doc](https://docs.google.com/spreadsheets/d/1fCQ3yTbu6y2uKMM4IIEljzAZgHX2FFeG2y9XwWy7G-g/edit#gid=0), write in the customer name and chosen DSE using the "suggesting" mode. Any of the Service Engineers with admin access in Zendesk can then [create the trigger](/handbook/support/knowledge-base/zendesk/create_dse_trigger.html), and "accept" the suggestion. Having the google sheet allows for greater visibility within the organization since not everyone knows their way around Zendesk or SalesForce.
- Related section of the [Sales handbook regarding premium support](/handbook/sales/#premium-support).
- To make sure that these subscribers are served well, even when their dedicated SE is not directly
available, there is a view in Zendesk to display all "dedicated" tickets so
......
......@@ -2,7 +2,8 @@
layout: default
title: Support Knowledge Base
---
- pages = sitemap.resources.select { |resource| resource.path.start_with?("handbook/support/knowledge-base/categories") }
- pages = sitemap.resources.select { |resource| resource.path.start_with?("handbook/support/knowledge-base") }
- pages = pages.reject { |page| page.data.title == "Support Knowledge Base" }
- pages = pages.group_by { |page| page.data.category }.sort_by { |category| category }
%ol.breadcrumb
%li You are here:
......@@ -37,4 +38,4 @@ title: Support Knowledge Base
%li
%a{:href => "#"}
%span.badge.pull-right> #{kb_pages.count}
#{category}
\ No newline at end of file
#{category}
......@@ -96,7 +96,7 @@ _Typically started in first week, completed by end of third week_
You will keep one installation continually updated on Digital Ocean, just like many of our clients. But you need to choose where you would like to test other installations. TODO: We need to list some benefits of each choice here.
1. [ ] Submit an issue on the [GitLab infrastructure issue tracker](https://gitlab.com/gitlab-com/infrastructure/issues/) titled 'Add <name> as a developer in Digital Ocean'.
1. [ ] Set up your [local test environment](https://about.gitlab.com/handbook/support/knowledge-base/categories/general/local_test_env.html)
1. [ ] Set up your [local test environment](https://about.gitlab.com/handbook/support/knowledge-base/general/local_test_env.html)
1. [ ] Choose your preferred test environment between Local VM's or Digital Ocean and put it in a comment below.
Installation from source is not common but will give you a greater understanding of the components that we employ and how everything fits together.
......
......@@ -33,6 +33,7 @@ feedback into GitLab.
- Accurate, nuanced, direct, and kind messaging.
- Being able to work independent and respond quickly.
- Able to articulate the GitLab mission, values, and vision.
- Understand the difference between different online developer communities
- You LOVE working with the GitLab community.
## Relevant links
......
---
layout: job_page
title: "People Operations Specialist"
---
## Responsibilities
- Responsible for the day to day administration of People Operations, and assisting team members with their People Operations questions.
- Assist the Sr. Director of People Operations to develop the strategic direction for People Ops, and implement the functional steps to achieve those goals.
- Develop and implement HR policies, from recruitment and pay, to diversity and employee relations.
- Prepare contracts for employees and contractors on quick turnaround and follow-through with smooth onboarding of new team members.
- Coordinate with our payroll and benefits providers, and using our People Ops Information System and ATS; currently BambooHR and Workable.
- Assist and advise managers in delicate and difficult People Operations issues (special circumstances, conflicts, sickness, layoffs, etc.)
- Create People Operations processes and strategies following the GitLab workflow, with the goal always being to make things easier from the perspective of the team members.
- Keep it efficient and DRY.
- Provide assistance to the team with miscellaneous support tasks.
- Maintain the hiring pipeline and ensure proper follow-up. Participate in recruiting, screening, and reference calls.
- Suggest and implement improvements to People Operations, for example for performance reviews and various types of training.
- Help write job descriptions and promotion criteria.
- TODO
## Requirements
- Prior extensive experience in an HR or People Operations role
- Clear understanding of HR laws in one or multiple countries where GitLab is active
- Ability to work strange hours when needed (for example, to call an embassy in a different continent)
- Excellent written and verbal communication skills
- Enthusiasm for, and broad experience with, software tools
- Proven experience quickly learning new software tools
- Willing to work with git and GitLab whenever possible
- Willing to make People Operations as open and transparent as possible
- Wanting to work for a fast moving startup
- You share our [values](/handbook/#values), and work in accordance with those values
- The ability to work in a fast paced environment with strong attention to detail is essential.
- TODO
......@@ -308,7 +308,12 @@ Below is the last section containing a more formal description of terms and keyw
| [artifacts:expire_in](http://docs.gitlab.com/ce/ci/yaml/README.html#artifactsexpire_in) | Used to delete uploaded artifacts after the specified time |
| [pipelines](http://docs.gitlab.com/ee/ci/pipelines.html#pipelines) | A pipeline is a group of builds that get executed in stages (batches) |
Don't miss these GitLab CI stories as well:
- [Migrating from Jenkins to GitLab CI](https://about.gitlab.com/2016/07/22/building-our-web-app-on-gitlab-ci/)
- [Decreasing build time from 8 minutes 33 seconds to just 10 seconds](http://beenje.github.io/blog/posts/gitlab-ci-and-conda/)
See also:
- [Learn how to set up deployment pipeline to multiple environments](https://about.gitlab.com/2016/08/26/ci-deployment-and-environments/)
- [Migrate from Jenkins to GitLab CI](https://about.gitlab.com/2016/07/22/building-our-web-app-on-gitlab-ci/)
- [Decrease build time with custom docker image](http://beenje.github.io/blog/posts/gitlab-ci-and-conda/)
......@@ -37,6 +37,6 @@ This is a chance for anyone in the GitLab community to get involved, even if you
## Questions? More info?
GitLab team members [@markglenfletcher](https://gitlab.com/markglenfletcher) [@ClemMakesApps](https://gitlab.com/ClemMakesApps) [@haynes](https://gitlab.com/haynes) will be on hand to answer questions and close issues.
GitLab team members [@markglenfletcher](https://gitlab.com/markglenfletcher) [@ClemMakesApps](https://gitlab.com/ClemMakesApps) [@haynes](https://gitlab.com/haynes) [@axil](https://gitlab.com/axil) [@afolson](https://gitlab.com/afolson) will be on hand to answer questions and close issues.
Image: "[Smash](https://www.flickr.com/photos/schatz/3893795729)" by [Richard Schatzberger](https://www.flickr.com/photos/schatz/) is licensed under [CC BY-SA 2.0](https://creativecommons.org/licenses/by-sa/2.0/#)
---
title: "GitLab 8.14.2 released"
author: Alejandro Rodríguez
author_twitter: eReGeBe
categories: release
---
Today we are releasing version 8.14.2 for GitLab Community Edition (CE) and
Enterprise Edition (EE).
This version resolves a number of regressions and bugs in the [recent 8.14
release](/2016/11/22/gitlab-8-14-released).
Please read on for more details.
<!-- more -->
- **CE/EE:** Rephrase some system notes to be compatible with new system note style ([!7692])
- **CE/EE:** Create tag after running pre-hooks and pass updated SHA to post-hooks ([!7700])
- **CE/EE:** Fixed commit time not rendering after initial page load ([!7704])
- **CE/EE:** Prevent error when submitting a merge request and pipeline is not defined ([!7707])
- **CE/EE:** Fix: Timeout creating and viewing merge request for binary file ([!7713])
- **CE/EE:** New system note design for commit discussion ([!7721])
- **CE/EE:** Refresh project authorizations using a Redis lease ([!7733])
- **CE/EE:** Fixed issue boards issue sorting when dragging issue into list ([!7734])
- **CE/EE:** Fix for builds with no start date throwing an error in cycle analytics events ([!7738])
- **CE/EE:** Clean up JiraService ([!7756])
- **CE/EE:** Update GitLab Workhorse to v1.0.1 ([!7759])
- **CE/EE:** Fix pipelines info being hidden in merge request widget ([!7808])
- **CE/EE:** Update Sidekiq-cron to fix compatibility issues with Sidekiq 4.2.1 ([!7815])
- **CE/EE:** Fix a transient spec failure ([!7825])
- **CE/EE:** Fixes access to the wiki code with git when repository feature disabled ([!7832])
- **CE/EE:** Revert bump in rufus-scheduler ([!7844])
- **CE/EE:** Make deleting with optimistic locking respect NULL ([!7867])
- **CE/EE:** Remove caching of events data ([!6578])
- **CE/EE:** Fix broken external links in help/index.html ([!7582])
- **CE/EE:** Evalute time_ago method instead of printing it ([!7634])
- **CE/EE:** Resolves updated and resolved status is not showing ([!7655])
- **CE/EE:** Fixed resolved discussion timeago not rendering ([!7656])
- **CE/EE:** Pick valid event objects for the events list ([!7689])
- **EE:** Port of rephrase-system-notes to EE ([!913])
- **EE:** Get rid of user activites table and replace it with redis ([!915])
- **EE:** Geo: Display Custom Avatars in secondary nodes ([!904])
- **Omnibus GitLab:** Revert default IPv6 configuration for NGINX ([!1133])
[!913]: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/913
[!915]: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/915
[!904]: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/904
[!1133]: https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/1133
[!7692]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7692
[!7700]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7700
[!7704]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7704
[!7707]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7707
[!7713]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7713
[!7721]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7721
[!7733]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7733
[!7734]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7734
[!7738]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7738
[!7756]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7756
[!7759]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7759
[!7808]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7808
[!7815]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7815
[!7825]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7825
[!7832]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7832
[!7844]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7844
[!7867]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7867
[!6578]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6578
[!7582]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7582
[!7634]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7634
[!7655]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7655
[!7656]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7656
[!7689]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7689
## Upgrade barometer
This version has no migrations and should not require any downtime.
Please be aware that by default the Omnibus packages will stop, run migrations,
and start again, no matter how “big” or “small” the upgrade is. This behavior
can be changed by adding a [`/etc/gitlab/skip-auto-migrations`
file](http://doc.gitlab.com/omnibus/update/README.html).
## Updating
To update, check out our [update page](https://about.gitlab.com/update/).
## Enterprise Edition
Interested in GitLab Enterprise Edition? Check out the [features exclusive to
EE](https://about.gitlab.com/features/#enterprise).
Access to GitLab Enterprise Edition is included with a [subscription](https://about.gitlab.com/pricing/).
No time to upgrade GitLab yourself? Subscribers receive upgrade and installation
services.
......@@ -60,7 +60,7 @@ We want to achieve our goals in the following order:
While we achieve our goals one by one, this doesn't mean we will focus on only one goal at a time. Simultaneously, we'll grow our userbase, get more subscribers for [EE](https://about.gitlab.com/features/#enterprise), grow [GitLab.com](https://about.gitlab.com/gitlab-com/), develop [products](https://about.gitlab.com/pricing/#gitlab-ee), realize our [scope](https://about.gitlab.com/direction/#scope), and make version control usable for more types of work.
We realize our competitors have started earlier and have more capital. Because we started later we need a more compelling product that covers the complete [scope](https://about.gitlab.com/direction/#scope), that is integrated out of the box, and that is cloud native. Because we have less capital, we need to build that as a community. Therefore it is important to share and ship our [vision for the product](https://about.gitlab.com/direction/#vision). The people that have the most knowledge have to prioritize **breadth over depth** since only they can add new functionality. Making the functionality more comprehensive requires less coordination than making the initial minimal feature. Shipping a small part of a big vision as quickly as possible sometimes goes against our instincts. However leading the way is needed to allow others to see our path and contribute. So when in doubt, the rule of thumb is breadth over depth, so everyone can contribute.
We realize our competitors have started earlier and have more capital. Because we started later we need a more compelling product that covers the complete [scope](https://about.gitlab.com/direction/#scope), that is integrated out of the box, and that is cloud native. Because we have less capital, we need to build that as a community. Therefore it is important to share and ship our [vision for the product](https://about.gitlab.com/direction/#vision). The people that have the most knowledge have to prioritize **breadth over depth** since only they can add new functionality. Making the functionality more comprehensive requires less coordination than making the initial minimal feature. Shipping functionality that is incomplete to expand the scope sometimes goes against our instincts. However leading the way is needed to allow others to see our path and contribute. So when in doubt, the rule of thumb is breadth over depth, so everyone can contribute.
## Principles
......
......@@ -11,8 +11,9 @@ extra_css:
.training-content
%h1.text-center Training
We organize training workshops to help your organization implement Git and GitLab quickly.
%h3 End user training
%p End user training workshops focus on Git concepts and the GitLab workflow.
%h3
%a{href:"/training/learn-gitlab-with-git.html"}Learning GitLab with Git Basics
%p This workshop focuses on how the GitLab UI works and how to integrate it and Git into your workflow.
%h3 Git workshop
%p A Git workshop covers Git concepts such as committing, branches, merge requests, merge conflicts, tags, cherry-picking, bisecting and rebasing.
%h3 GitLab flow workshop
......@@ -31,7 +32,7 @@ extra_css:
%h3 Cost for each workshop is $2,500
%p
Workshops are delivered via web-conferencing and are recorded for up to 20 people.
Each workshop takes approximately 4 hours.
Each workshop takes approximately 2 hours.
%p
And we're open to discussing other materials to cover and other durations.
Please fill out the form below if you are interested.
......
---
layout: default
title: Learn GitLab with Git Basics
suppress_header: true
extra_css:
- training.css
---
.wrapper
.training-picture-container
.training-overlay
.training-content
%h1.text-center
Learning GitLab with Git Basics
There are two sessions, 90 minutes each. Session 1 is built around re-enforcing how the UI works, and then paralleling that in the command line. Session 2 focuses on Merge Conflicts in the UI and command line and Git/Hub/Lab Flow.
%h3.text-center
Session 1: GitLab UI & Git Command Line (90 Minutes)
%h4
Part 1: The UI (45 minutes)
%h5
TODO: INSERT VIDEO HERE
GitLab is software that allows you to do a lot without having to use the command line. In this session, all participants will work together to commit code with the instructor and understand the GitLab interface through action and practice.
The UI also includes some advanced git features, and we dive into those topics at the end of the first session when we cover branching and what Git is and how Git fits into the GitLab equation.
%h4
Part 2: Command Line (45 minutes)
A core part of using Git and GitLab includes using Git locally on your computer to make changes and push these changes to the server. We use the command line (where Git is born and thrives) to make simple changes to some local files and push them to the server. This mirrors the work we did in the UI in the first session and bridges the gap of how GitLab and Git work together.
%h3.text-center
Session 2: Merge Conflicts & Git Flow (90 minutes)
%h4
Part 1: Simple Merge Conflicts in the UI (60 minutes)
%h5