Meeting minutes for May 19, 2008

Sakai/OSP 2.4 Status

Sakai/OSP 2.5 Status

Outstanding issues:

Sakai/OSP 2.6

Sakai/OSP 2.6 and beyond Development Status (OSP Design and Development)

Functional Team Review: Community Ideas for Future OSP Releases: Evaluations 

Bottom line: we voted for Beth's Option C: Simplify slightly by only allowing selection of qualified individual evaluators (qualified means the user has the evaluate permission and is a group member if required). This leaves the onerous queries only to the selection of evaluators, and not the evaluations themselves. It might also be worthwhile to add an option to select all qualified individual evaluators (and make this the default).

Beth sent out email about Evaluations, which was discussed. Option B, only those with permission to evaluate get to, and you don't select evaluators. was rejected base on IU's use case. Evaluators who don't have permission can't even open. They anticipate different evaluators for senior year than freshman. In general they are concerned with privacy issues. So Beth proposed Option C: allow selection of evaluators for individual cells, but get rid of selecting by role. You're presented with a list of users who have permission to evaluate (including filtering by group, so if you can't view a matrix, you can't evaluate). Question: is this a simplification of multiple evaluator spec. So doesn't interfere with future implementation of multiple evaluators. Do we eliminate the tool permission? Beth thinks then you'll have students listed. Then filter by role? IU: evaluate permission eliminated in current IU. Lynn thinks that's a problem. Certain abilities are implicit in a role rather than determined by permissions, so users with same permissions see the same thing (e.g., see ) Evaluate v. review. Range of uses: 1. Whoever sets up the matrix wants granular control over who sees what v. 2. open, collaborative, where even students see each other's work. Have permission to evaluate but not be selected as evaluator. Option C, you are presented with a list of people who have permission to
Default - if you don't select evaluators, everyone with permission to evaluate can evaluate. Noah: rethink interface for granting permissions. Permissions dashboard that show permissions across tools. Not now. Maybe there should be a link to OSP permissions overall. Not now. Should this be written up as a Jira, or does it need a feature template. Yes, feature template. This is like one of Multiple Evaluator use cases. Beth will look to make sure we don't do anything that would make that harder to implement. LOI: When there is more flexibility with roles, it will be easier to provide multiple evaluator behavior. User and site have multiple roles? E.g., can't make someone both a reviewer and an evaluator, have to make them coordinator. In any case, simplifying system now will make Multiple Evaluator stuff easier. IU: it would be good to be able to add permissions for an individual. One IU req: blind evaluation. If prof can see stuff in matrix, doesn't matter that it's blind in Eval tool. Permission to see user list? If you can't see user list, you have to use the Eval tool. 2. Now one evaluator can't see another's evaluation. But there are times when it would be appropriate to collaborate. Permission: view evaluation (see someone else's evals). If you have useful defaults set so it doesn't change current behavior, that would be okay. IU 2.1 - permissions not worked out adequately, so not very usable. In best of all possible worlds, what would permissions look like. Lynn wrote it up, will share with community. Having other people look at suggestions would be helpful.

Status on Reviewed Proposals:

Misc

On Deck: