Education Program

About

GitLab’s Education program is part of the Community Programs team.

On this page, you’ll find information about the GitLab for Education Program Team, our vision, our methods, our initiatives, and our program requirements.

The primary mission of the GitLab for Education Program is to facilitate and drive the adoption of GitLab at educational institutions around the globe and build an engaged community of GitLab evangelists and contributors in the next generation of the workforce.

Additionally, the Education Program seeks to evangelize the benefits of an all-remote operating model and GitLab’s associated company values with students.

How to reach us

• DRI: @Akarsten1
• Email: education@gitlab.com

Additionally, see the following Slack channels.

Vision and goals

The vision of the GitLab for Education Program is to enable educational institutions to be successful in teaching, learning, conducting research with GitLab. We seek to build an engaged community of GitLab users around the world who actively contribute to GitLab and each other’s success, and ultimately become evangelists of GitLab in the workplace and beyond.

Our goals are:

• Align the program structure and license offerings with the needs and operating models of educational institutions while providing the best GitLab has to offer to students, faculty, and staff.
• Grow the base of educational institutions, students, faculty, and staff using GitLab.
• Build a robust and engaged educational community full of members who collaborate, contribute, and enable each other to be successful with GitLab.
• Build meaningful relationships with the Education Program member institutions.
• Provide a wealth of resources for adopting GitLab in an educational setting including course materials, case studies, code examples, syllabi, and presentations.
• Evangelize the benefits of DevOps as a discipline and GitLab as the leading single application for the DevOps lifecycle.
• Bring DevOps into the classroom in related disciplines such as computer science and infrastructure technology.
• Be a thought leader in the discipline of DevOps by engaging with related academic disciplines, academic organizations, and associations.
• Evangelize the benefits of an all-remote operating model and GitLab’s associated company values to the next generation of the workforce.

What we’re working on

GitLab for Education Program issues typically exist in the Education Program subgroup of the Developer Relations Group. But they may also reside in Field Marketing, Corporate Marketing, or other marketing subgroups.

Work labels

We use the following labels to track our work across these spaces.

OKRS and KPIs

We track progress on OKRs using the Education Program and OKR labels.

The GitLab for Education Program has one Key Performance Indicator and several Performance Indicators. See the Developer Relations Department Performance Indicators page for more details.

How to help

Alumni are an important part of every school’s community. You can assist the GitLab for Education team by connecting GitLab to your alma mater. To get started:

• Email former professor you really liked and share information about our GitLab for Education Program. Email template coming soon.
• Contact your alumni association about “Alumni updates” and share what you do at GitLab.
• Contact student organizations you were part of, especially if as realted to software or digital technology in some way.
• Offer to visit your alma mater virtually to give an “Introduction to DevOps guest lecture”

GitLab for Education Program

In order to qualify for the GitLab for Education Program, applicants must meet the GitLab for Education Program Requirements. Once accepted in the program, institutions must agree to and are subject to the GitLab for Education Program Agreement.

GitLab for Education Program requirements

In order to qualify for the GitLab for Education Program, applicants must:

• Be a qualified educational institution: A qualified educational institution is one that has been accredited by an authorized agency within its applicable local, state, provincial, federal, or national government and has the primary purpose of teaching its enrolled students. Qualified educational institutions can be public or private and must be non-profit/non-commercial. For reasons relating to trade controls, we are unable to accept applicants from Cuba, Iran, Syria, North Korea, Russia, Belarus, or Ukraine.
• Meet the use case requirements: The GitLab educational license can be used solely for the purposes of instructional use or non-commercial academic research. Instructional use includes activities related to learning, training, research and development. Non-commercial academic means conducting not-for-profit research projects conducted by the program member, and not at the request of a third party, which are not intended to, or in fact, produce results, works, services, or data for commercial use by anyone to generate revenue, or for the benefit of a third party. The GitLab educational license cannot be used for commercial, professional, or any other for-profit purposes. Specifically, it is not authorized for use to run, administer, or operate an institution.
• Be a full-time faculty or staff member at the qualified educational institution: We can only issue licenses to full-time faculty or staff who are directly employed full-time at the educational institution. Students who may also be employed in a staff role cannot apply.

Please note: the decision to issue a GitLab license via the GitLab for Education Program is always at the discretion of GitLab. If you have questions on the application and decision making process, please contact education@gitlab.com.

Examples of educational institutions that qualify

• K-12 institutions include Elementary, Middle, and High Schools, which may include both publicly and privately funded institutions (Note: GitLab.com (SaaS software) is not available to K-12 institutions. However, K-12 institutions may apply for GitLab self-managed instances.)
• Junior Colleges, Community Colleges, and Technical Schools
• Universities
• Research Institutes or Centers directly owned and operated by a University

Examples of entities that do not qualify

• Training centers
• Churches and libraries
• Medical research centers or institutions associated with a hospital or health care system
• Independent research laboratories
• Re-training programs
• Military schools, institutes, or training centers within a branch of the military
• Research institutes or National Laboratories that are owned by a Federal Government
• eLearning platforms not directly affiliated with or operated by an accredited academic University
• Coding academies, bootcamps, or independent learning platforms

Examples of acceptable use cases

• Classroom use: All activities related to the instruction of students in the classroom
• Non-commercial academic research: Activity related to not-for-profit research projects at an educational institution that are not conducted for the benefit of a third party.
• Organizational use: Activity related to a club or organization at an educational institution as related to the development of students; this could include open source student clubs, robotic clubs, engineering clubs or the like. Note that the non-acceptable use cases still apply to clubs and organizations.

Examples of non-acceptable use cases

• Information technology/professional use: Use for maintaining or running the infrastructure, technology or otherwise, of the institution
• Administrative use: Use for any administrative functions of the institution including program management, planning, marketing, and service delivery
• Commercial research: Research conducted by any commercial programs or entities operated by or affiliated with the educational institution for a commercial purpose.
• Third party directed research: For example, the US Government may open a request for proposals for a specific project with a well-defined results. Research laboratories, owned and operated by a University such as an Advanced Research Laboratory (ARL), may apply and be awarded the project in the form of a contract. This type of work, with the goal of benefitting a third party through producing a given outcome, rather contributing to the general body of scientific research itself, does not qualify. An Advanced Research Laboratory or entity of the like, can still hold and apply for a GitLab for Education license but any work completed for the benefit of a third party, or under contract for example, cannot occur on the free license.
• Services: Any activities conducted by a consulting center, super computer laboratory, or entity that provides services for the benefit of a third party are not acceptable under the free license.

Issuing licenses to students

At this time, GitLab does not issue licenses directly to students as part of the GitLab for Education Program. Students are welcome to encourage their educational institution to apply to the program directly. Students can access a free subscription for GitLab.com or a free download of our core self-managed offering. Students can also apply for a 30-day trial if they would like to test more advanced features of GitLab. Children under the age of 13 are not permitted to use GitLab.com (SaaS Software).

Requests for support

When we are reviewing opportunities or requests for support, we must be able to answer yes to each of these questions to move forward with the work:

1. Will this work support, grow, and/or engage the GitLab for Education community?
2. Can it grow the skills and abilities of the education evangelist to ultimately make them a better resource to our community?
3. Is there a measurable impact on the GitLab for Education community? This can include influence on a GitLab KPI, progress on an OKR, or completion of responsibilities that are defined in the GitLab handbook.
4. Has an issue been created with the appropriate labels to define the work and assign a DRI?

If the answer to any of the above questions is “no”, our team will collaborate with each other and the requestor to do one of the following actions:

1. Make adjustments so we can take on the work.
2. Find another team that is better suited to deliver the work.
3. Come to an agreement that the work should not be done.

Evangelism on social media

The GitLab for Education team builds thought leadership, connects with our community, and increases our reach on social media. We use social media and community engagement to reach stakeholders across the world. On social media, we evangelize the following topics:

• Education and learning: Tips from own experience: Workshops, slides, blog posts, videos, etc.
• Events live tweets / tweet storms: Amplify talks with screenshots and messages.
• Community best practices and GitLab insights
• Live demos and lesson plans

X/Twitter and LinkedIn are our primary platforms. Both platforms have different target audiences and content distribution. We are always careful to choose the right platform to accomplish our goals, keeping the following guidelines in mind:

• Keep the message short and appealing. If you have multiple sentences, break them down into a list.
  • 💡 Use emoji as list markers, this one to learn something.
  • 🏗 This way users learn what you want to share and build together.
  • 🔥 Choose the right emoji. This one expresses a fast success for example.
• Minimize hashtag use. Often a single hashtag is good enough, but too many clutters the message.
  • #education or #DevOps can be used, but make sure to only include relevant tags.
• Too many emoji can hide key messages.
• Use an appealing screenshot image or funny animated GIF to make people stop when scrolling.
• Do not start with an @ character on X/Twitter, this can be hidden as reply and hinder audience reach on X/Twitter. You can add a period at the end, or restructure your sentence to work better with an intro. Hey @gitlab, how's the new release looking?

Education Evangelists strive to become thought leaders on social media platforms. We do this with the following guidelines and strategies in mind:

• Attract more active followers and therefore improve impression numbers and engagements.
  • Users can follow you on LinkedIn, you do not need to accept every invitation. If you plan to extend your business network, ensure that profile details such as private email/phone are not shared with anyone.
• Help and educate users
• Analyse profile statistics
  • The why on the most impressions, top media tweet or most engaging tweets
• Follow users who share interesting stories
  • They may follow back, increasing the follower count.
• Retweet with comment and add your own thoughts or a funny emoji.
  • Mix this with “normal” retweets.
• Engage with tweets, like often, add replies and join the discussion.
  • Say Thanks for sharing :emoji: whenever needed
  • Share positive vibes
  • Follow the team member social media policy
• Listen to criticism and ignore hate speech.
• Do not criticize GitLab competitors.
  • Instead, engage with their communities and learn how to improve.
• Channel back feedback to product and engineering teams.
• Adopt new ideas with live streaming or community coffee chats.
  • Engage community members in discussions.
  • Tag people and keep the tone “at the table”
• Just as you are more than your work, your social accounts are more than work related. Be yourself and don’t be afraid to share your own life to the degree that you’re comfortable with.
• Share your impressions and thoughts on work with #allremote and #remotework
• Regularly tweet about daily work. Use the hash tag #LifeAtGitLab to share insights and funny moments.
• Pick outstanding GitLab features from another stage/group and post about them (could be a blog post, screenshot, etc.).
  • Share praise in Slack with linking the Tweet/LinkedIn URL.

Evangelism on Bambu

Bambu is an app used to create suggested posts so other GitLab team members can use their own social media accounts to tweet relevant and useful articles, media, and other information to their own networks. The Education Evangelist should take the training available (Note: you must be logged into your GitLab unfiltered youtube account to view) to become a curator in order to be able to provide content to spread awareness of the Education program. Once you’ve finished the training, tag the Social Media specialist in an issue and request access. From there, follow the instructions in the handbook. Finally, add yourself to the table of known curators on the curator page.

Types of content that work well for Bambu include:

• Media like podcasts, videos, interviews, and live streams related to the Education program
• Articles written for the GitLab blog
• Articles written for dev.to related to education or the education program
• Articles about the GitLab for Education program or team members
• Case Studies about University partners
• GitLab for Education landing pages

Bambu is not for announcements, workshop sign ups, or to start new initiatives. It’s more of a place to show off what’s already happened with the team.

Evangelism on Twitch

The Education team uses Twitch as part of its broader community outreach strategy to create a catalogue of presentations, shows, and resources for people looking to learn GitLab or increase their knowledge of the program. See the education program’s dedicated workflow page for complete instructions on hosting Twitch sessions.

Evangeism with blog posts

Content will either be published on the GitLab Blog, where all our blogposts include the education-program postType in their front matter for proper tracking.

If the blog post is not featured on the GitLab blog, posts will publish on the GitLab group Dev.to.

Evangelism on YouTube

Recordings from past workshops and other team activities can be found on the GitLab Unfiltered channel on YouTube.

Evangelism with presentations at events

Participation in events such as conferences and conventions are an important part of education evangelism at GitLab. In the case of Education Evangelism, both tech and education events are important to take part in. An Education Evangelist seeks out relevant organizations and events to participate in as part of their role. As events and organizations to consider are found we will add them to an issue in the Outreach project.

When preparing for presentations and talks, post your slides to the Developer Advocacy Slack channel for feedback on slides. This ensures that the most current messaging is being used. It’s also good for a sanity check and quick edit on the content. Another good way to review for a speaking engagement is to post a zoom room to the speaking channel and ask for people to join a practice session.

Education Evangelists should consider being a part of the Speakers Bureau.

The booth kit should include current assets like tall vertical banners, a backdrop, and various tools for setting up the booth. Use the following checklist to ensure you’re prepared for booth duty.

[ ] zip ties
[ ] backdrop
[ ] side banners
[ ] power cords needed for laptops and monitor
[ ] scissors
[ ] packing tape (strong and not "crystal clear")
[ ] power strip
[ ] monitor for demos
[ ] stickers and small swag
[ ] business cards

The venue will provide details on shipping and handling for the booth assets.

Things to remember:

• Always use FedEx Express Saver.
• Use the general FedEx GitLab Account. Do not use the field marketing account.
• Check the estimated shipping times in order to ensure the package arrives at the proper time. Note that many venues charge per day to hold packages and will only keep them for a set number of days.

Before the conference begins, create an issue in the Education project Outreach titled Name of Conference Location Date and make it confidential. Assign attendees of the conference to the issue. Inside comments, create several comment threads including Flights, Hotel, Booth Assets, Swag, and any other planning threads as necessary. Use this issue for all planning related to the execution of the conference booth and/or talk or presentation. If there is no booth, still coordinate in the issue with threads relevant to whatever the team has planned for this event.

We try to connect with as many potential program members and current program members as possible at the conference. In order to solidify those connections, we try to send out any emails related to the conference within 2-3 weeks. This includes workshop follow ups as well as a MailJet email if we have access to the attendee emails.

• At each event the EDU team attends and sponsors, gathering names and emails is an important part of our booth work. Using this form template we gather permission to contact them as well as some other important pieces of information. Depending on the event, we may receive a list of attendees that have opted-in to be contacted.
• From there, prospects must be added to Salesforce and then added to Outreach. This process involves Marketing Ops and the instructions are available on their handbook.
• Follow the instructions to create a copy of the Google Sheet provided for putting your collected information and then create an issue using the issue template.

There are several organizations in the education world that are relevant to the audiences that GitLab for Education is looking to reach. This includes computer science, information systems, and general research faculty. In order to reach these communities, it’s important to support and attend conferences these organizations hold. This allows us to connect directly with professors, researchers, and other important stakeholders in education and discover how we can best support their endeavors with students.

Association for Computing Machinery

ACM is the Association for Computing Machinery and is the world’s largest educational and scientific computing society. There are several special interest groups within ACM, many with their own conferences and events. We focus on two of these.

1. SIGITE SIGITE (pronounced Sig-eye-tee-ee) is the Special Interest Group on Information Technology Education. It is part of the Association for Computing Machinery. SIGITE focuses on IT education. This is an important field for GitLab for Education as this education pertains directly to the Ops in DevOps. Their annual conference is
2. SIGCSE SIGCSE (pronounced Sig-see) is the Special Interest Group on Computer Science Education. This group is designed for discussions around "…development, implementation, and evaluation of computing programs, curricula, and courses…" This is where we can meet people who fit the dev side of DevOps.

Association for Information Systems

AIS is the Association for Information Systems and is a professional organization focusing on information systems, often closely associated with business degrees. AIS has several conferences that are regionally operated as well as one that is an international conference.

1. ICIS (pronounced I-C-I-S) International Conference on Information Systems
2. AMCIS (pronounced am-sis) Americas Conference on Information Systems
3. PACIS Pacific Asia Conference on Information Systems
4. ECIS European Conference on Information Systems

Each of these conferences present unique opportunities to connect with the information systems community, often the education that many future CIO and project managers will be going through.

ISCAP/EDSIG

ISCAP/EDSIG is the Information Systems and Computing Academic Professionals and Education Special Interest Group. This group runs two concurrent conferences, EDSIGCON and CONISAIR. This is another Information Systems opportunity with a different group. These conferences can be a bit smaller, but with more chances to connect on a personal level with faculty and students attending.

Evangelism with in-person visits to campus

Some events will include visiting a campus directly and providing a lecture or workshop for educators or students. We have a variety of workshops and lectures, some of which are listed in the DevOps Education Guide Project. These are organized by the Education Evangelist directly with a student group or professor or other relevant campus representative. Make sure you create an issue in the outreach project with details of the time, location, and tentative plans. Update this as you communicate with the relevant campus representative. Tag the GitLab Community Programs manager or your direct manager in the issue to receive written approval for the event. Swag should be coordinated with Boundless and shipping coordinated with the relevant campus representative. Providing food for an event outside of normal class hours is not expected, but is highly encouraged. The food budget is part of the swag budget for the quarter.

An Education Evangelist will likely only do campus visits in the 1st and 3rd quarters since these most overlap with university semesters. Every effort should be made to have several events in one visit, either with one school or with surrounding schools in order to justify the cost of an overnight trip (airfare, lodging, food, etc.). Discuss plans with a manager before agreeing to or offering an in-person visit in order to ensure you are only offering what can be done. Since in-person events are more intensive and require more planning, an Education Evangelist should consider doing only 1-2 campus visits a quarter in addition to other events (Education Specific conferences, community events, etc.). We can always schedule a virtual lecture or workshop instead of in person.

Evangelism with virtual guest lectures

GitLab for Education offers a DevOps 101 lecture, aka “Intro to DevOps: Software Development in Practice” for professors looking to introduce or strengthen DevOps concepts for their students. There is a Google form for signing up for this type of lecture. When a new repsonse is recorded, or after an event where we solicitied sign ups, the Education Evangelist will send emails using this approved copy to begin planning virtual lectures with the interested parties.

Summary of evangelism types

*UMV is Unique Monthly Visitors and is reported by the media agency.

How evangelists work

All of our work is stored as issues in the Education Program Group. Issues are stored in projects.

Measuring our success

The GitLab for Education Team tracks our impressions on the Education Program Impression Dashboard. All outreach should be entered into the Education Asset Inventory Google Sheet in order to appear in the dashboard. Directions for entering each publication are in the Read Me tab of the spreadsheet.

We track impressions for all content created (videos, blog posts, articles, etc). Generally, we measure the total number of impressions after the content has been published for 30 days. In order to stay on track with recording impressions, each team member should create a monthly recurring Impressions calendar task on the first day of the month. Each time a piece of content is published, a link should be added to the calendar task. On the first day of the new month, each team member should check impressions for the content and enter the metrics for those items into the Education Asset Inventory Google Sheet. If it hasn’t been 30-days since the content was live, wait to enter the metrics until the next invite.

We collect X/Twitter impressions and LinkedIn views as part of our impressions metrics. Social Media impressions originating from Education team member’s account are entered in the Social Media Impressions tab of the Education Asset Inventory Google Sheet. This sheet currently serves as our record while we working on adding a social media widget to the dashboard itself.

Social media impressions originating from the official GitLab account at the request of the Education team may be reported at the discretion and availability of the Social Marketing team. If you wish to record impressions from an official post, request metrics on the social coverage issue 30 days after the post goes live.

Impressions are recorded at the end of each month and entered into the sheet:

• X/Twitter: Each team member records the total number of X/Twitter Impressions (original content and retweets) from the Analytics Dashboard on Twitter for each month. If GitLab official tweets are reported upon, include these as well.
• LinkedIn: Each team member records the total number of views of posts, articles, and documents for each month. If GitLab official posts are reported upon, include these as well.

View page source - Edit this page - please contribute.