Skip to main content
All CollectionsLive Courses and Maintenance Implementing Changes and Reporting Issues
Writing a GitHub Pull Request
Writing a GitHub Pull Request

Learn how to write a GitHub pull request and what information to include.

Amy Peterson avatar
Written by Amy Peterson
Updated over 3 years ago

GitHub pull requests are the primary way you will interact with the Content Team to implement edits to your course. As such, it is very important that you structure your pull requests clearly and include enough information for the Content Team to easily and efficiently process your request.

Please note that all edits must be reviewed by the Content Team. Please allow 3-5 business days for edits to be reviewed and implemented. 

Making a pull request

Step 1 

After using the Content Quality Dashboard to identify which exercises need to be updated or changed, open the course in the Teach Editor and create a new branch using the branches button at the bottom left. In the new branch, make your changes. For more information on using Teach to make changes, see this article.

Step 2

After you've made your changes, wait for the Course Build to finish.

  • If the Course Build passes, great! Move to the next step. 

  • If there are any build warnings are related to your code (e.g., a syntax error), work to diagnose the issue and resolve the warnings.

  • If there are any build warnings related to SCTs (e.g., no call of a function was found), please note those in your pull request.

  • If there are any other issues with the build, please note this in your pull request.

Step 3

Go to the GitHub repository of the course and make sure to select the correct branch. Open a pull request, and describe the changes you’ve made using the template below. Then tag @datacamp-contentquality as a reviewer (not as an assignee). The team will review the changes and request additional clarification if needed.

Performing maintenance on a Spreadsheets course: 

Spreadsheet courses work a little differently and require different steps to make edits. 

Step 1

After using the Content Quality Dashboard and determining what fixes need to be made, open an issue on GitHub and detail the changes you want to be made, following the format in the template below.

Step 2

Assign the issue to @datacamp-contentquality for review.

Step 3

Done! The DataCamp Content Team will contact you if any clarification is needed and will implement the requested changes.
​

Pull Request Template

All pull requests should include the information contained in this template. Being as descriptive as possible will help the team to review your changes quickly and move the updates to the live course as efficiently as possible.

Hi @datacamp-contentquality,

This pull request addresses [a general overview of the issues addressed].

SCTs will need to be edited for Exercises [exercise numbers where SCTs need to be edited].

Changes made:

  • A bulleted list of changes made to each exercise.

  • For example, Exercise X.X: added a hint about the size argument of the sample() function to address learner confusion about its use.

  • If any changes were made to the solution code, SCTs will need to be updated.

  • For example, Exercise X.X, Step X: Changed the variable name df to a more informative name, olympic_medals. This will require changes to the SCTs.

  • If any slides were changed, please include those too.

  • For example, Exercise X.X, Slide 5: Fixed typo in second bullet point.

Example Pull Request

Here's an example pull request made by a DataCamp instructor.

Hi @datacamp-contentquality, This pull request covers multiple minor corrections and adjustments to the course in response to user feedback over August and September. One such adjustment (for Chapter 1, Exercise 2, "Portfolio returns during the crisis") will require a new SCT, to test the learner's use of the .head() DataFrame method. The performed adjustments are: Ch. 1 Ex. 2: Added scaffolding for printing of the .head() of the portfolio DataFrame, in response to user feedback that they did not know what dataset was being used--this will require an SCT update; Ch. 2 Ex. 3: 1) removed scaffolding from the CVaR_95 definition (code line 9), due to user confusion; 2) switched scaffolding for axvline to line 13, to help user identify its use in code line 14 (rather than the other way around, which was causing confusion with hist); Ch. 2 Ex. 11: Adjusted instruction and hint to emphasize that negative_cvar is an argument without parentheses; Ch. 3 Ex. 2: Updated scaffolding to include norm in the VaR_95 definition (code line 8); Ch. 3 Ex. 6: Step 1: added more information to the SCT message regarding the number of assets (four), as additional guidance following an incorrect response; Step 3: added information in the instruction that the variable steps was being introduced for simplicity, so that 1/total_steps didn't need to be written over and over; Ch. 3 Ex. 9: Updated hint to highlight that .ssr is an attribute, not a method (and hence has no trailing parentheses); Ch. 3 Ex. 13: Updated comment on code line 4 to emphasize that extreme values are those values of backtest_data exceeding the 95% VaR; Ch. 4 Ex. 3: Steps 1 and 2: typo fixes, removing incorrect returns references and replacing with losses references; Ch. 4 Ex. 6: Changed variable x to loss_range to help learner identification of x-axis variable, and updated hint accordingly. This change does not appear to require an SCT update. Many thanks for your time! Best Regards, xxxxx

Did this answer your question?