Virginia Tech has moved this project to a top priority. Will be looking at 2.7 to merge the tool locally. Chris suggests putting it in trunk first and then we can backport from there. IU has a similar timeframe regarding upgrades to 2.7. Virginia Tech will move to 2.7 at the beginning of May.
Some features in reports and some in osp. Put in trunk and then move to institutional instances of 2.7.
The OSP community stealthed the reports tool but may still be there. Not included in any of the builds. Getting it back into trunk is not a huge issue. Status of tool: Pulled out of releases because of lack of support. Line between core and contrib is fuzzy at this point. It may stay in contrib until running better and has a better support base. Even if VTech is running it locally, need to get more support locally to continue to run it. Marc Z wants VTech to have a role in supporting OSP, but other things come up that compete.
IU is running the Reports tool now. The tool needs work to make it run more like other Sakai tools - run global and local reports. Now when you run reports, it is visible in all sites, instead of specific to the site with the data. One aspect that is fairly problematic. Chris agrees that support for site-specific data is probably the next thing to work on. Fairly easy problem to fix. At worst, a couple of days.
Will there be a clear path for institutions to go and get the report? We will attach patches to the Jiras for people to access. Assume we will put a patch to apply to trunk and to backport to other versions of Sakai. This is how it would have to be done under the current model. If the Reports tool was its own release, it would be different. You could use a specific version of the reports tool.
What kind of special knowledge would be needed to install the tools? Just like if you want to use Assignments2, you know there is this other tool out there that you need to get. Sort of separate. Have to go get it and put it in. Might be better ways to do some packaging of that. Just drop these things into Tomcat and you are done. Ultimate goal is to have a separate Reports release. Now for VTech to get this work done, has to do some work on the OSP tools. Would have to modify osp in some way. If you want to use reports IU has developed, you would have to make those changes. Version 1 is reports code as it is now in trunk. Version 2 supports IU reports, but will require you to update OSP. Reasonable if can get to where certain level of support is available. Can make it worth it for people to upgrade osp to allow the use of reports.
Reports needs to be a tool that is moving. There has to be some value there. There is currently no value to it. Chicken and egg. No one is using it so no one is adding value. VTech needs the report, so will make value-added changes. IU has same need. This is really still the best way to do it, because that is where the data is.
What about a Jira ticket for this work? Dave can create a Jira to show what would have to happen to upgrade osp to get the reports tool to work. Then we can open up additional issues for feature requests. Dave has the information to get started but has not yet had the time to unpack it. Hopefully doing it this week. If it is reasonable, he can jira it as he goes. Existing Jira to merge the IU code base into trunk SAK-18464. Only open Jira that is relevant. There are 14 issues reported in Jira. In a very future meeting we could go through them. They could also be listed on the reports page.
OSP separate release cycle could not get traction. All the stuff OSP relies on would have go with it. OSP still tied to the release process.
Dave now has an adjunct teaching position, has been unable to make the OSP Community meetings due to his schedule. VTech needs this tool so is committed to getting it done.
A name for a minspec on reports
First Proposal: I want to gather and analyze portfolio data related to managing the portfolio process, aggregating student evidence in support of standards at a particular level of achievement, and identifying relevant student artifacts. (This one is too specific. These attributes can appear in the minispec itself.)
Final Choice for Reporting Minispec: I want to gather, analyze, and display portfolio data to support institutional, programmatic, course, and individual assessment processes.
Update on UDel work with Serensoft Form Parser
Perhaps in a future meeting we can talk about a process for continuing support for form parser - can someone own it? Who owns it right now? There for the taking? Is UDel in a position to take this on?
To take on continuing support of a tool, there would have to be a pretty active development phase at first, later on-going bug fixes, steady but slower rate, would require some networking effort, developers would have to join the OSP Jira Team
Next steps for this group:
Institutional ownership of forms parser
Building out further the reports that IU developed. There is a foundation there. A foundation that makes it easier to create new reports. For example, there is a report to drill down into summary data for a matrix cell, drill further to see detailed reports for each student. Could there be a report showing the file attachments for each cell. Developer could create the report in less than an afternoon. Use IU reports as a foundation and build out. Nice to build up a library of reports.
IU has less than a person now for OSP, use determined by IU. UMich has only some development support.
RWU did a presentation in DC to a group of deans of architecture. Showed what they had put together. Sakai combined with website that pulled content in. Response was incredible. Others came up and said if they could get some of what RWU has done, they would be willing to move.
There is more institutional interest in using Sakai than in developing Sakai - RWU is modeling how people can join in the functional effort.
New Jersey Institute of Technology - one and only attempt at a virtual accreditation in architecture. Have four full time developers using Sharepoint to do this. Said if they could get visual thumbnails of files as part of project, would offer their four programmers to collaborate with RWU. Kaltura may be a solution for the issues that NJIT is grappling with.