Collaborating with the Data Science Team

The Data Science team is here to help! Don’t be concerned about asking us any questions related to the projects. If we don’t know the answer, we’ll be sure to help you find someone who does.

If you have any questions check with your TA and then reach out to the DS Team.

You can contact us via [email protected].

When submitting a ticket, please make sure you follow the DS Ticket Question Checklist below.

DS Team Project Review:

As the team works through the project, it can be helpful to get to get a different perspective on the research plan. The DS team is happy to join your lab and provide feedback on the current progress and future plans for the project.

The DS team are not experts in all things. However, it can still be helpful to get a new perspective on your plans.

If you’re not sure, our advice is to go ahead and schedule a meeting. You never know what may come out of the discussion.

When scheduling your review session, please follow the steps below:

  1. Notify your Corporate Partners contact that you plan to schedule a DS review.

  2. Send an email to [email protected] with the subject of "DS Team Review - <Team_Name>".

    • Be sure to replace <Team_Name> with your team’s name.

  3. Prepare! Make sure your team has the items below ready before the review:

    • A summary of all the research that has been completed.

      • Make sure to explain why you made the choices that you made.

    • Plans for the next step in your research.

      • It’s OK if they are still theories. This about discussion, not a specific grade.

    • Updated documentation and a link that can be shared with the DS team.

      • It’s very helpful if the DS team can review the content in advance.

      • Otherwise, we are trying to understand everything as it’s being presented.

    • Speaking plans for the review.

      • Sometimes it can be difficult if the team doesn’t know who is covering each part.

    • Be careful about code reviews.

      • Some people can site read code. However, that shouldn’t be your assumption. Make sure the information can be understood quickly during the presentation.

DS Ticket Question Checklist:

When troubleshooting a problem, there are often common questions that we ask in order to understand what we can help you with. Please read and answer (if you can) the items below. If your problem doesn’t fit any of these, no worries! We are still here to help.

  • Could you please describe the issue that you are facing? (We use these descriptions to help understand the problem)

    • Include screenshots and copy paste the code that you are having issues with if it isn’t in a notebook.

  • Bad example: “I’m getting this error when I try to import. <image inserted>”

  • Good example: “I’m trying to import the python package, pandas, using the code below. When I attempt to import the code, I receive the error message ‘this is just a test’. I attempted the troubleshooting steps below, but so far nothing has worked. Could you please help me find a solution? <troubleshooting steps inserted>”

  • What’s the absolute path to your code?

    • Its format should be something like this: /anvil/projects/tdm/corporate/your_team/file.py

    • Often, we will attempt to run your code to see if we’ve fixed the problem or to better understand the issue.

    • If the code is stored locally (on your computer, or in your home directory), please move it to the data depot (/anvil/projects/tdm/corporate/your_team/…​) so that we can access it.

  • Bad example: “My code is untitled.ipynb.”

  • Good example: “The notebook I am attempting to run can be found at /anvil/projects/tdm/corporate/your_team/examples/my_code.ipynb”

  • What troubleshooting steps have you tried so far?

    • Be sure to include who was involved in the troubleshooing so we know which people in include in an email update.

    • We are always here to help, but The Data Mine is all about learning. It’s important to try different solutions before you ask us for help.

    • We also encourage working with your teammates. Students come from all types of disciplines and may have a different approach or a different skillset.

    • In general, the more detailed your troubleshooting information, the better.

  • Bad example: “I ran the code cell and it didn’t work.”

  • Good example: “I received the initial error and I found a few of the links below online talking about the problem. I attempted these 3 solutions <solutions listed>, but they all had different errors. I’m not sure where to go next.”

  • Is there a minimum reproducible example that you could provide?

    • When troubleshooting, it’s common to try and reduce the complexity of the problem. If you are hitting an error at the very end of a complex process is there a way to reduce the complexity and hit the same error?

    • If there is, then it’s valuable to send us that example (it’s easier to troubleshoot). However, more often than not you’ll find a solution to the original problem when trying to build the simpler example.

  • Bad example: “<No code provided>”

  • Good example: “I was working on a complicated table join and I managed to identify the part that I think is causing the issue. I reduced each dataset down to 4 rows of relevant data and included my code below, but I’m still hitting the error.”

Don’t worry if you get stuck. Everyone (including every member of The Data Mine staff) gets stuck. The important thing is to continue working and find resources when you need them.