snDevs: How do I contribute?

I’ve always wanted to contribute but setting up github has always seemed like a terrifying journey for me. And yet today I was able to successfully submit my first pull request to the snDevs Slack PointsThing main branch!

I will be the first to say that I am not the most technical person out there and I rely heavily on researching everything… and asking my friends for help. Thanks to Earl Duque’s help, today i’m going to be sharing my experience with helping out with the PointsThing bot on the snDevs slack channel.

First, a few terms. I know, I know. I promise, it won’t be too scary.

• GitHub - This is a website. It’s used as the source control for a lot of different programs/applications/websites, and is where the code for the PointsThing bot is hosted. You can find tons of open source stuff to contribute to and help out with if that’s something you’ve wanted to do.

• Repository - I like to explain data by talking about buckets. This is the big pool that holds all the water that is each specific application. You don’t touch this, you just borrow water from it.

• Fork - This is your bucket. There are many out there, but this one is yours. You fork a Repository in order to have a copy of it so when you accidentally blow something up, you don’t have to explain to everyone else why you broke production. It’s not a good feeling… just dump your bucket out and get a new fresh bunch of water from the big pool and you’re good to start again!

• Branch - This is a little cup of water that you will experiment in (make your development changes in)… this metaphor is entirely out of control. It’s basically an update set.

• Pull Request - When you are done with your bucket and you’ve added and changed and removed everything you wanted, you bring your bucket back to the life guards to see if they want to dump the water back in the pool.

Now that we have the painful part out of the way, let's get started. A quick way to summarize this will be as Earl put it…

Got that?

Me neither. (jk i love you earl)

So let’s take it step by step.

First, here are your resources:

• The repo Earl Linked

• The internet

• This blog (hint: You’re already here, take a seat and grab a blanket and maybe some hot cocoa)

Step 1. Fork

Not like the one you have in your kitchen, go put that back. Ok so the way to get this done is to first have your GitHub account created, and navigate to the link above in our resources.

Once you are here, navigate over to the right and click on “fork” (that number next to it just shows how many other forks exist). Select the account you want to fork to and then you’ll be redirected to your own little forked version of the application.

Step 2. Add to your PDI via Studio

This one took me a little while to quite figure out. I was used to just going straight to studio and linking it there, but they have this new feature in ServiceNow called “Credentials”. I’m not sure when they added them, but now you are required to create a credential record in order to link to a repo. Here is a really good set of instructions on how to add an application from source control to your PDI/Instance from the developer.servicenow.com learning plans.

Once your set up looks something like mine, you select your application and move on to step 3.

Step 3. Branch in Studio

First you should click on “Source control” in the top menu and then “Create Branch”.

After that give it a fancy name and you’re good! At minimum, your branch name should say what the feature being added is or a good descriptor of the purpose of the branch. Jace made a pretty great post over at the ServiceNow Developer Blog concerning how people could contribute to Hacktoberfest and went in to detail about “What is a quality pull request”. I would highly recommend you read over that post as well to see some of the standards they expect when contributing to anything related to the Developer program (just like Slack Points Thing!).

Step 4. Edit app

Now is the fun part. This new branch is going to act like the update set that is going to hold all your stuff - now you actually get to do some ServiceNow Development!

Pictured: MGOPW working

Step 5. Submit PR from branch to repo [he] linked

Once you have completed all your changes, it’s time to submit your pull request for review. This should be the easy part. For some reason the ServiceNow docs page I linked above had instructions that seemed backwards, so if those don’t work do it in the order I show below.

First go back up to Source Control in the ServiceNow Studio and click on “Commit changes”. It will load the files you want to push to GitHub and then ask you for comments. Make sure you add everything you did to the comments so others know what is going on.

Next you should go to your repository in GitHub and it will tell you that you had recent pushes to your branch.

Click on “Compare & Pull Request”.

Here you’ll see a bunch of information overload, but basically what it’s saying is “We are comparing your bucket (branch) to the big pool (master branch of the repository you forked) and we noticed changes. If you click on “Create pull request” you will submit these changes to the big pool for review!”

Click on that green button!

AND YOU DID IT!

Pat yourself on the back. You have now done what many others say they want to do. Good job dude! Go grab yourself your favorite drink, take a break, and let the impending nerves of whether your hard work gets accepted or not wash over you… and then let them go. No need to dwell - now that you know how to do it go submit more pull requests!