Sixth Week Update

It's great to finally see surveys in the wild, and while there are a few rough edges, the feature should serve admirably, and the thorough refactoring that has taken place over the last week and a half highly reduces the amount of technical debt and will make it very easy to add new features and tweaks through subclassing/superclassing.

There are two outstanding requirements for surveys. And yes, they are indeed requirements, as if we are finishing construction of the railroad after the train has already left the station. Fun!

These requirements are 1) nagging notifications and 2) grade activation.

The SurveyRecordGroup entity kind that I've written about before makes both of these much more simple than they would otherwise be. At first, I was thinking that we could just use some logic at runtime to figure out whatever we'd need to send notifications for untaken surveys and to activate grades.

But after a plethora of hypothetical scenarios, it became apparent that unless we created a new entity kind tying together a given survey, a given project, and the status of that project before and after the survey, we'd open ourselves to all kinds of implausible but still possible bugs that might take much longer to find and fix if not nipped in the bud.

For instance, what if one mentor takes the midterm survey, and then the mentor has to drop the project for some reason and another mentor has to take the next survey? Or what if - as will likely happen for GHOP - there is not simply two surveys, but an arbitrary 'n' number of surveys, with an arbitrary choice of statuses for the project in question?

And what about mentors who must take a given Grading Survey more than once for several student projects? How would we avoid any complications or mistakes that might come up, such as giving the wrong grade to a project?

And finally, how could we be sure - positive, in fact - that we're not activating grades for a given set of surveys more than once? If all the students end up getting paid twice - or not at all - I *really* don't want to be the one responsible.

Luckily, SurveyRecordGroup solves this by using the status of the project when the survey is taken, and after the survey is activated. It's very simple and intuitive to use, such as in the following snippet:

# get SurveyRecordGroup for this survey and survey taker
program = survey.scope
for project in program.student_projects.fetch(1000):
this_record_group = SurveyRecordGroup.all().filter(
"project = ", project).filter(
"initial_status = ", project.status).get()

In addition to nagging notifications and activation, the third related feature that I'll be working on this week is a complete series of smoke tests, not that we need it right now, but they'll make it much easier and safer for someone to develop on top of the surveys and make sure they haven't broken anything.


After finishing up these final survey features, I look forward to being able to now dedicate much more attention the news feed that is my primary GSOC project.

I've already submitted patches of News Feed code and the Newsfeed Module wiki page is fairly up to date, but the current state of the news feed feature is a jumping off point, and I'd love to hear any ideas about news feed features that haven't yet been discussed. If you do have any, let me know!