Skip to content

Commit

Permalink
Resolve merge conflict
Browse files Browse the repository at this point in the history
  • Loading branch information
Becca Steinbrecher authored and Becca Steinbrecher committed Jul 20, 2022
2 parents b5a084d + 59f743d commit a3d6185
Show file tree
Hide file tree
Showing 75 changed files with 1,485 additions and 691 deletions.
24 changes: 0 additions & 24 deletions .github/workflows/approve.yml

This file was deleted.

Original file line number Diff line number Diff line change
Expand Up @@ -16,9 +16,10 @@ published: true
alt="GitLab plus Sourcegraph logo"
/>

<BlockquoteWithBorder
quote='Sourcegraph has the best find-definition, find-references, and intelligent code navigation capability on the planet - and they brought it to GitLab.'
author='Sid Sijbrandij, GitLab CEO'
<Blockquote
quote="Sourcegraph has the best find-definition, find-references, and intelligent code navigation capability on the planet - and they brought it to GitLab."
author="Sid Sijbrandij, GitLab CEO"
center={true}
/>

Check out the below video where Quinn sat down with GitLab CEO Sid Sijbrandij to discuss the native GitLab integration, and why Sourcegraph's code intelligence means better code reviews and improved code quality for [GitLab Enterprise](https://about.gitlab.com/solutions/enterprise-class/) customers and open source projects on [GitLab.com](https://gitlab.com/explore).
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -13,9 +13,10 @@ heroImage: /blog/gitlab-integration-preview-dark.png
published: true
---

<BlockquoteWithBorder
quote='Sourcegraph has the best find-definition, find-references, and intelligent code navigation capability on the planet - and they brought it to GitLab.'
author='Sid Sijbrandij, GitLab CEO'
<Blockquote
quote="Sourcegraph has the best find-definition, find-references, and intelligent code navigation capability on the planet - and they brought it to GitLab."
author="Sid Sijbrandij, GitLab CEO"
center={true}
/>

With the [GitLab native code intelligence integration from Sourcegraph](/blog/gitlab-integrates-sourcegraph-code-navigation-and-code-intelligence), you can bring IDE-like features such as hover tooltips and go to definition to every GitLab code view. The below screencasts show you how to enable the Sourcegraph integration for both GitLab CE/EE and GitLab.com.
Expand Down
4 changes: 2 additions & 2 deletions content/blogposts/2020/ex-googler-guide-dev-tools.md
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,7 @@ socialImage: /blog/exgoogler-campfire.jpg
published: true
---

Many years ago, I did a brief stint at Google–yes, I’m an ex-Googler or Xoogler. A lot has changed since then, but even that brief exposure to Google's internal tools left a lasting impression on me. In many ways, the dev tools inside Google are the most advanced in the world. Google has been a pioneer not only in scaling their own software systems but in figuring out how to build software effectively at scale. They've dealt with issues related to codebase volume, code discoverability, organizational knowledge sharing, and multi-service deployment at a level of sophistication that most other companies have not yet reached. (For reference, see <a href="https://www.amazon.com/Software-Engineering-Google-Lessons-Programming/dp/1492082791" rel="nofollow" target="_blank">Software Engineering at Google</a>.)
Many years ago, I did a brief stint at Google. A lot has changed since then, but even that brief exposure to Google's internal tools left a lasting impression on me. In many ways, the dev tools inside Google are the most advanced in the world. Google has been a pioneer not only in scaling their own software systems but in figuring out how to build software effectively at scale. They've dealt with issues related to codebase volume, code discoverability, organizational knowledge sharing, and multi-service deployment at a level of sophistication that most other companies have not yet reached. (For reference, see <a href="https://www.amazon.com/Software-Engineering-Google-Lessons-Programming/dp/1492082791" rel="nofollow" target="_blank">Software Engineering at Google</a>.)

<Figure
src="/blog/exgoogler-campfire.jpg"
Expand Down Expand Up @@ -50,7 +50,7 @@ At every stage in this process, there is typically a tool that anchors the devel
|-----------------------------------------------------|--------------------|------------------------------|
| Identify feature or bug | Issue Tracker | GitHub issues, Jira |
| Read code | Code search | Your editor, <a href="https://oracle.github.io/opengrok/" rel="nofollow" target="_blank">OpenGrok</a>, <a href="https://github.com/hound-search/hound" rel="nofollow" target="_blank">Hound</a>, [Sourcegraph](https://about.sourcegraph.com) |
| Write code | Critique, IntelliJ, Emacs, Vim, VS Code | Everything except Critique |
| Write code | Cider, IntelliJ, Emacs, Vim, VS Code | Same, except no Cider <br /> *(Editor's update: since publication, Cloud IDEs like Gitpod and Codespaces have gained more traction)* |
| Test code | Blaze | A bit of the Wild West, but <a href="https://bazel.build/" rel="nofollow" target="_blank">Bazel</a> is gaining traction |
| Review code | Critique | <a href="http://github.com/" rel="nofollow" target="_blank">GitHub</a> PRs, <a href="https://www.gerritcodereview.com/" rel="nofollow" target="_blank">Gerrit</a>, <a href="https://www.phacility.com/phabricator/" rel="nofollow" target="_blank">Phabricator</a>, <a href="https://reviewable.io/" rel="nofollow" target="_blank">Reviewable</a> |
| Deployment | Borg | <a href="https://kubernetes.io/" rel="nofollow" target="_blank">Kubernetes</a> |
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -36,13 +36,14 @@ The A-Z format introduces simple concepts in a fun and easy-to-understand way so
id="6bCO63O4swI"
/>

<BlockquoteWithBorder
quote={`Dinosaurs, llamas, and dump trucks are cool—but so is coding. At Sourcegraph, many of us, myself included, have young children who now see us working on the computer all day. We love software development and wrote this book as a fun way to share our passion for coding with our kids.`}
author='Quinn Slack'
<Blockquote
quote="Dinosaurs, llamas, and dump trucks are cool—but so is coding. At Sourcegraph, many of us, myself included, have young children who now see us working on the computer all day. We love software development and wrote this book as a fun way to share our passion for coding with our kids."
author="Quinn Slack"
center={true}
/>

We hope you enjoy the book and would love to get your feedback [via Twitter](https://twitter.com/intent/tweet?text=For%20all%20children%20at%20home%20that%20wonder%20what%20their%20techie%20parents%20do%20all%20day%2C%20night%2C%20and%20some%20weekends%2C%20too%2C%20they%20need%20the%20%22Our%20ABCs%3A%20Always%20Be%20Coding%22%20book%20by%20@sourcegraph%20-%20https%3A//about.sourcegraph.com/abc%20%23ABCsbook) or [email](mailto:[email protected]).

<div className="align-items-center justify-content-center d-flex">
<a href="https://twitter.com/intent/tweet?text=For%20all%20children%20at%20home%20that%20wonder%20what%20their%20techie%20parents%20do%20all%20day%2C%20night%2C%20and%20some%20weekends%2C%20too%2C%20they%20need%20the%20%22Our%20ABCs%3A%20Always%20Be%20Coding%22%20book%20by%20@sourcegraph%20-%20https%3A//about.sourcegraph.com/abc%20%23ABCsbook%20%23TYCTWD%20%23TODASTW%20%23BringYourKidsToWorkDay" className="btn btn-primary mt-4" className="btn btn-primary my-4">Click to Tweet</a>
</div>
</div>
Original file line number Diff line number Diff line change
@@ -0,0 +1,87 @@
---
title: 'How NativeScript Onboards New Open Source Contributors'
authors:
- name: Justin Dorfman
url: https://twitter.com/jdorfman
publishDate: 2022-07-20T10:00-07:00
description: 'Developer onboarding is one of those things that can be overlooked when growing an open source community. The team behind NativeScript has been hard at work onboarding developers who want to contribute to the project and ensuring that they do so in a scalable and consistent way.'
tags: [blog, ospo]
slug: 'how-nativeScript-onboards-new-open-source-contributors'
published: true
heroImage: https://storage.googleapis.com/sourcegraph-assets/blog/nativescript-open-source-onboarding-blog-hs.jpg
socialImage: https://storage.googleapis.com/sourcegraph-assets/blog/nativescript-open-source-onboarding-blog-hs.jpg
---

![](https://storage.googleapis.com/sourcegraph-assets/blog/nativescript-open-source-onboarding-blog-hs.jpg)

From my experience working with open source projects over the years, I noticed many of them (including popular ones) don't have an onboarding process. I get it, it's a lot of work, and when you have 300+ issues to triage over the weekend, that’s the last thing on your mind.

The team behind [NativeScript](https://nativescript.org/), on the other hand, has been hard at work onboarding developers who want to contribute to the project and ensuring that they do so in a scalable and consistent way.

In this article, we’ll explore the project a little and look at how the onboarding process works because there are some broader lessons to learn for all of us working within open source software when it comes to community building and operational best practices.

### What is NativeScript?

At its core, NativeScript allows developers to directly access native platform APIs from JavaScript. Before NativeScript, this was a bit clunky, and it’s been a breath of fresh air to see just how streamlined the process can now be thanks to it.

The resulting experience minimizes language switching and IDE jumping – a huge improvement for the developers who rely on these modalities.

The project is part of the [OpenJS Foundation](https://openjsf.org/), the neutral home for JavaScript, and it finds itself in excellent company with some other awesome projects of various types.

When you look at the roadmap, it’s easy to see why this project has garnered its reputation. The continued effort to improve core underlying infrastructure is worth its weight in gold for anyone who wants to leverage JavaScript APIs to enhance their projects.

**_"The team has mentioned that having more hands-on sessions with regular contributors and maintainers would further improve the process because it helps to scale the understanding of the general process – which in turn speeds up the merging of contributions for future releases."_**

### What Does the Onboarding Process Look Like for Developers?

The current cadence for contributors is about 10-15 people per month outside of the [core team](https://github.com/orgs/NativeScript/people). While some are regular, there is also a healthy turnaround of new contributors – all of which need to be onboarded effectively to maintain consistency across the codebase. The team has acknowledged just how important a seamless onboarding process is, especially as things grow and expand.

The onboarding itself is quite a quick and painless process with most of it being self-driven. The majority of contributors do so via their own forks and this tends to take care of itself. However, when a contributor starts to be more active on a regular basis, the team will chat to them about [guidelines](https://docs.nativescript.org/#bring-your-own:~:text=making%20code%20changes-,Guidelines,-%23) and [best practices](https://docs.nativescript.org/best-practices/) that will help to bring them into alignment with the wider project conventions. Typically this will happen using Slack, GitHub, Discord, email, and Zoom as needed.

![](https://storage.googleapis.com/sourcegraph-assets/blog/nativescript-nathan-walker-discord.png)

<center>
_Nathan Walker, NativeScript maintainer, is helping out a new contributor in Discord._
</center>

The reason for this is that it helps to be proactive about the code conventions ahead of time, rather than trying to fix things later. The more coherent and consistent the initial contributions are, the less time and effort are wasted later on down the line.

The team has mentioned that having more hands-on sessions with regular contributors and maintainers would further improve the process because it helps to scale the understanding of the general process – which in turn speeds up the merging of contributions for future releases. In addition, a recorded session would also help to disburse some of the key information more widely.

**_"Unfortunately, those who don’t pay attention to these conventions make things much more difficult than they need to be."_**

### What Makes for a Successful Contribution?

NativeScript has a wide range of use cases, and contributions that show a nuanced understanding of these are the most valuable. Typically this requires the contributor to take special care of the existing conditions in the code and leverage the functionality to create something new. Unfortunately, those who don’t pay attention to these conventions make things much more difficult than they need to be.

Taking some time here to align a contribution with the existing code style is a surefire way to be helpful and useful – and it's something that is greatly appreciated by the NativeScript team.

**_"a crucial part of scaling the impact of the project and ensuring that it receives the attention it needs to continue to be an impactful part of the JavaScript ecosystem."_**

### What About the Path Towards Becoming a Maintainer?

Over the past 3-4 years, the team has seen more and more contributors becoming regular maintainers for the NativeScript project. This is great to see for a 10-year-old project, and it bodes well for its future. While the project was part of [Progress](https://www.progress.com/nativescript), there were a number of [nStudio](https://blog.nativescript.org/the-next-chapter-for-nativescript-nstudio/) developers who played an active role, and they took over the responsibility of being sole maintainers when Progress passed the project back to the community.

nStudio did a great job before bringing the project to the OpenJS Foundation to help build out more community stewardship. In the past year, three new community contributors have been part of the [Technical Steering Committee](https://github.com/NativeScript/management/blob/master/nativescript-governance.md) (TSC) and are actively involved in maintaining the project.

As things continue to grow and gather steam, we expect to see more maintainers emerge to continue the great work that has been done so far. This is a crucial part of scaling the impact of the project and ensuring that it receives the attention it needs to continue to be an impactful part of the JavaScript ecosystem.

### Conclusion

Developer onboarding is one of those things that can be overlooked when growing an open source community – but you do so at your peril. By setting a precedent upfront and helping to bring new contributors into your ecosystem, you are investing in the future of your project in a very sustainable way.

If you need help with onboarding at work, [read this guide](https://about.sourcegraph.com/guides/dev-onboarding-how-is-it-unique?utm_source=nativescript-blog-set-up-demo&utm_medium=nativescript-blog).

---

_Thanks to the following people for helping with this post: Jory Burson, Nathan Walker, Marcos Placona, and Fabiana Castellanos._

#### About the author

Justin Dorfman is Sourcegraph’s Open Source Program Manager and is responsible for
fostering the adoption of code intelligence in the open source community. You can chat with Justin on Twitter [@jdorfman](https://twitter.com/jdorfman) or our community [Discord](https://discord.com/invite/vqsBW8m5Y8)

### More posts like this

- [How we analyzed hundreds of repositories to ensure they had open source licenses](https://about.sourcegraph.com/blog/batch-changes-ospo)
- [No Secrets! Quickly find sensitive files in your GitHub repo](https://about.sourcegraph.com/blog/no-more-secrets)
Loading

0 comments on commit a3d6185

Please sign in to comment.