Evidence Based Scheduling (by Joel Spolsky)
Mentors can now evaluate students based on their past performance, and evaluations have been built for an arbitrary number so that in a future cycle an evaluation could theoretically be given once a week or so, but these evaluations are nonetheless discrete, backwards-looking measures.
An improvement to this feature would be to have more continuous data . Since SOC is built specifically for software projects, most projects could likely make use of a post-receive hook or other form of automation. The goal would be to not measure a student's performance in the past, but to be able to make predictions such as whether a project will be completed on schedule. This will allow earlier intervention, and will make it more possible to make the mentoring process generally more data-driven.
This would also help us measure performance at a more fine level. As Spolsky notes, as the size of a task decreases, the ability to accurately measure it increases:
When I see a schedule measured in days, or even weeks, I know it’s not going to work. You have to break your schedule into very small tasks that can be measured in hours. Nothing longer than 16 hours.
This forces you to actually figure out what you are going to do. Write subroutine foo. Create this dialog box. Parse the Fizzbott file. Individual development tasks are easy to estimate, because you’ve written subroutines, created dialogs, and parsed files before.
In the last day, I've posted a new patch for NewsFeed tasks, and I should be posting another shortly that completes e-mail notification functionality.
One major functionality that has been holding up this second patch is the ability to perform an access check that can work for the widest range of feed item senders and receivers (the NewsFeedModule wiki page has a definition of these). Because this feature needs to be able to work with a variety of model schemas, I wanted to find the lowest common denominator. Of course, this should be the use of scope logic to determine the relationships between entities. But the original specification for NewsFeed envisioned some type of updates that are difficult even with scope logic. Because of the complexity of this feature, I think it's all but necessary for me to provide some smoke tests that make sure that these checks are working properly.
And the next step in feed-customization is to provide a UI and logic for users to set their own feed preferences for e-mail notifications (the plan as of now is to allow e-mails to be customized but for XML feeds to only include public info and not be customizable).
I should soon be ready to focus more on the secondary NewsFeed features, and I'm especially interested in prototyping how we could use post-receive hooks and real-time push notifications to make the newsfeed feature more useful for collaboration.