Code Contributions Support Pod

Purpose

Provide a space for SEs to collaborate in the context of Code Contributions.

Current objectives

• Raise awareness for the pod
• Use async communication in the #spt_pod_code-contributions Slack channel to empower SEs and exchange knowledge

Support Pod members

• Lead: Anton Smith (@anton)
• Co-Lead: Manuel Grabowski (@manuelgrabowski)
• Brie Carranza (@bcarranza)
• Ronald van Zon (@rvzon)
• Cleveland Bledsoe Jr (@cleveland)

How to get involved

1. Talk with your manager.
2. If you haven’t yet, consider working on the Code Contributions Support training module.
3. Add Code Contributions to your knowledge areas in the Support Team data. If it already exists, adjust your level accordingly – any level is welcome in the Pod!
4. Optionally: Let the team and your SGG know about your new focus area.
5. Join the #spt_pod_code-contributions Slack channel.
6. Add yourself to this page.

Regular meetings

• None at this point, but setting a sync session up is just a Slack message away!

Ways to Collaborate

• Slack channel: #spt_pod_code-contributions

In addition to collaborating with fellow Support Engineers, consider some of these opportunities for collaborating with other GitLab team members:

• Consider participating in Backend Pairs:
  • Slack channel: #backend_pairs
  • Subscribe to the Google calendar.
  • Watch the Backend Pairing playlist on YouTube.
  • Read about Backend Engineering at GitLab.
• Consider participating in Frontend Pairs:
  • Slack channel: #frontend_pairs
  • Subscribe to the Google calendar.
  • Read about Frontend Engineering at GitLab.

Finding a Code Contribution opportunity

🌊 Want to make a code contribution but you aren’t sure where to start?

• Search and filter issues strategically.
  • Have a play around with the labels to look around for issues depending on your interests. For easier issues you can search for Seeking community contributions, Accepting UX contributions and then add additional labels accordingly
  • If the issue has a weight, look for issues with a weight of 1 for smaller issues
  • @anton: I typically like to look for api labelled issues, because they tend to be backend only changes and Ruby code is what I like working on. Where possible I like to work on issues that will directly help Support in some way.
  • An interesting exercise would be to look at issues you opened early on in your time at GitLab to see how much you’ve grown since you opened the issue and to see if you could make a code contribution.
• For Support Stable Counterparts (SSCs): ask your product group if they have anything small you can work on.
• Audit events are normally easy ones to get into as there are plenty of examples to draw from. See the Comprehensive audit log: instance settings epic.
• Take a look at the Papercut spreadsheet.
• When you see something you might like to work on, add an emoji to the issue so you can refer to the emoji issue list later.
  • @anton: I personally use 🐜 so if you have seen an issue with that emoji from me, I’ve earmarked that issue for a potential code contribution in the future 😄
• Remember that there are plenty of code contribution opportunities outside of gitlab-org/gitlab. Consider gitlab-org/charts, gitlab-org/gitlab-runner or contributing to a project in the Support Toolbox.
• If you are interested on working on something but you aren’t quite sure how to get started, feel free to reach out to the product team that owns the issue or you can ask in #backend or #frontend. They can give you pointers and advise on the best approach.

View page source - Edit this page - please contribute.