2008-05-19 Conference Call

Owned by Former user (Deleted)
Last updated: May 19, 2008Version comment
4 min read

Meeting minutes for May 19, 2008

Sakai/OSP 2.4 Status

  • SAK-13271: Creating a new form item when adding evidence in matrix cell causes HTTP 404. John and Beth found it's a dup of another jira. Something from Resources. Maybe we should get rid of option to create a form in that workflow.

Sakai/OSP 2.5 Status

Outstanding issues:

  • SAK-12119/GM-151 No resources.
  • SAK-13468 Wizard tool does not retain artifacts during Preview Beth reported it last week. As a result, Preview is not worthwhile in wizard tool
  • SAK-13520 Edit Scaffolding Cell screen is very slow with many cells and users when a Matrix is sparsely populated. Resolved with fix version 2.5x. Adds a method to the API, but only implemented once. No one objects to adding the method. No one volunteered to do independent testing, so Beth will test it. Noah will post info about the change to the dev list to be sure no one objects or sees a problem.

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:

  • Multiple Evaluator Workflow - Functional design Status: waiting for resources. LOI does not have a programmer to do it. Will probably get to it after current needs met by IU and UM.
  • Form Data Extraction and Summary Data Presentation. Noah will look at jQuery grid plugin to use instead of ext.
  • Matrix and Wizard Defaults and Cell-level Access Control IU working on this for iteration 2. Nothing has changed since last reviewed. This would make everyone's life easier.

Misc

  • Goal Management and datapoint contrib support? Tabled until someone steps forward.
  • Paris Pre-Conference & BOF sessions Jan recently sent out email looking for assistance with Intro to OSP session. Intro followed by case studies. That's what Jan is looking for from people. They also want to have some developers available at the session so that questions can be answered. Send Jan 1-2 sentence rundown on what
  • SAK-13520 Edit Scaffolding Cell screen is very slow with many cells and users when a Matrix is sparsely populated. Brian at IU recently worked on same problem in another part of the code. Alan Berg ran automated check for places where there might be similar flawed techniques in use. Hibernate iteraters in n-squared and beyond loops. May be able to optimize these things with joins. This is something we should look at soon. Lynn: could this be why wizard performance is so slow? Quite possibly. Report posted here

On Deck:

  • Review, vote & prioritize outstanding OSP JIRA Issues