Specific project Pull Requests

Metadata additions

This is primarily for the following repos:

• Next Experience Recipes App (Deprecated)
• Next Experience Fleet Management App (Deprecated)
• Plants App
• Points Thing

In the above repos, it was encouraged that contribution could be as simple as adding a metadata record to the app to "help fill the database". Here's a quick way to recognize if the PR is valid without having to pull the entire app into an instance, and how to deal with the checksum conflict.

Recognizing the files

If it looks like one metadata link file and one checksum file, it's likely good to go:

Click into the sys_metadata_link file and verify that the targeted table is correct:

That's it! We're good to merge, since a data record can't break the app (usually) then we don't really need to look further into it.

Go ahead and merge the PR

Checksum conflict

Boooooo! Stupid, useless, not-even-used-anymore checksum file.

1. Click on Resolve conflicts
2. You'll see something like:

3. Your goal is to edit this text down to only what should remain.
   • Everything between the lines <<<<<<< and ======= are from the source branch (the submitter's branch)
   • Everything between the lines ======= and >>>>>>> are from the target branch (the production branch)
4. In the case of checksum, we always accept the incoming/submitter's version. So that means we want to delete lines 1 and line 3-5. So that only line 2 remains.

should end up like this:

5. Click Commit merge then I understand, update

5. Proceed to merge the PR as normal

ServiceNow App changes

This is primarily for the following repos:

• SNDevs Slacker Bot
• SNDevs Points Thing
• Menu Generating Operations Program Widget Custom Component
• Menu Generating Operations Program Widget Experience Page
• Plants App
• Instance Scan Checks

When a repo with a ServiceNow generated app gets updated from within ServiceNow, it's often almost impossible to understand the changes being made from simply reading the code in GitHub.

This event is more about participation and less about combing through the details, so our official stance for reviewers is:

It’s important that the content doesn’t look like spam. After a quick look, everything seems to be legit, as all the entries have valid comments. I haven’t reviewed every single one of them yet, but I’m mainly checking if it looks like spam and if it’s related to the topic it says it is. If it meets these criteria, it's good to go.

Accepting PRs without merging

This is primarily for the following repo(s):

• UI Builder Conference Notes App

When a repo has a dedicated list of stories to deliver that include items with minimal repeatability, we need to implement a process that allows developers to learn without blocking others from learning. Thankfully, Hacktoberfest has 3 systems for validly accepting a PR:

1. Performing a review and approving the contents of the PR
2. Assigning the hacktoberfest-accepted tag
3. Merging the PR

As such, with items where merging is not an option but the PR is a quality submission, the SOP is:

1. Assign the story to yourself
2. Start reviewing the submission (from the Files Changed tab of a PR on web)
3. Add feedback and mark the review as Approved. There is a template provided in the template page of the wiki
4. Apply the hacktoberfest-accepted tag/label to the PR
5. Close the PR without merging