Mentoring Next Steps

The two overarching pieces that connect my current Mentoring interface in the IDE to the API are making mentoring exist on the website and figuring out how suggestions and rules fit together.

The work on the community is mostly in the background. For now, administrators will create mentoring relationships, which keeps mentoring mainly in the IDE. However, in order for the suggestions and rules to reach any Looking Glass user, the information needs to be stored on the server and accessible through the database. In order for this to work, we need tables for Mentorships (relationships between mentor and mentee), Suggestions (the worlds that have been edited by mentors), Votes (the ratings for rules), as well as the code test and code test result tables that already exist. To get started using ruby on rails in the community, I created the Mentorship table and the functionality to create Mentorships. Once this is connected to the IDE, mentors will actually be able to view their mentee's worlds specifically, which helps push toward the next step, where mentors make suggestions for their student's world.

Before making the suggestion and voting tables, I need a stronger idea of what exactly a suggestion is and what information we want to store about it, so I have started working on that. I originally envisioned students receiving suggestions as tutorials, where they are shown how to reproduce the suggestion for their world. However, the new idea is to show students an example similar to their program and have them reproduce the suggestion for their code. In this case, we no longer need to generalize suggestions so that we can create the tutorial, but instead, present the suggestion such that the changes are clear. This means that when a mentor is rating a suggestion for their child or writing the code test, the mentor can view the original code and the code with the suggestion made, as this is what the novice programmers will see. This introduces a new challenge: how much of the code should be shown? Showing the entire program for the original and changes is likely to be overwhelming, but how can we determine which parts are important. In theory, the rule/code test will give us this information. The code test looks for all of the necessary requirements for the suggestion, so showing all of the passing constructs is a start. However, what if one is the first line and another is the last line? Is the code in the middle important? Even if they aren't, is it confusing to show two chunks of code from the same function without the pieces in between? I have started looking at the suggestions mentors made in the formative study to try to find a general way to choose which code to show that provides sufficient information, while minimizing information overload.