July 5, 2007 Agenda and Minutes

Connection Info

Sakai002 (Ad-hoc Meetings)

• Conference Code: 350
• PIN: 72524
• IP Address: 129.79.6.44
• Telephone: 812-856-7060

Agenda

• Current status of work on 2.4.x
• Notifications widget for revising content
• Indiana's proposal for popup with description
• Configuring JIRA to track workflow for maintenance branches and releases
• Issues for 2.5.0
• Deadlines for work on 2.5.0 (including design changes, code freeze, string freeze)
• Dublin Core
• Should we have regular meetings?

Attendees

• hilarious Harriet
• the most excellent Megan
• jolly Jim
• laughing Lance
• serious Stuart
• merging Mike
• conscientious Clay

Minutes

Indiana's proposal for popup with description

• The basic need is to surface resource descriptions, since this is a common faculty complaint
• IU's proposal is a pop-up/hover frame that displays the description. IU is going to be rolling this out by the end of the month, and has an interest in seeing this merged with the Resources tool
• There is no disagreement about the value of surfacing descriptions, but it's not clear that a pop-up would be the best way to do this:
  • descriptions can get quite long - couldn't this be a problem?
  • there are already complaints about the current pop-up menus; wouldn't a new pop-up simply exacerbate this?
  • a pop-up tacitly states that the description is secondary, but isn't it often more important than most of the fields already displayed by the Resources tool?
  • the Resources Viewer already treats this problem, although that can argue both for and against the pop-up solution (e.g. if the viewing is happening in RV, clutter in the Resources listing may be a little less worrisome)
• if we're going to do a pop-up, maybe it should show more than just the description
  • picture on how someone else has done this: http://www.flickr.com/photo_zoom.gne?id=327097697&size=o
• We should move ahead with IU's proposal in a new branch, and then conduct some usability testing with it
• Action item: someone at IU will create a Jira for this, following the new convention, and the new branch will be named after this JIRA
• we may include this for 2.5 (with options to enable it, but off by default), depending on usability testing and other community feedback
• See: http://bugs.sakaiproject.org/jira/browse/SAK-10581

Current status of work on 2.4.x

• Jim's a little behind on some issues, but those are getting worked on
• We will move ahead with a fix suggested by Colin for making the pop-up menus keyboard accessible, and that will go into the branch as a fix
• The jury's still out on whether we will try the DOJO widget at all, but if we do it will appear in the post-2.4 branch (and not the maintenance branch)
  • Clay is keen to see this, and Harriet thinks he's annoying about it can see it here:
  • http://sjb.atrc.utoronto.ca/dijit/tests/form/test_Button.html
• Action Item: Harriet will follow up with Colin

Notifications widget for revising content

• the problem in a nutshell: Resource notifications are being sent when files are being revised (i.e. overwritten), despite any notification preferences that suggest the contrary. This is an issue that could/should be dealt with in the maintenance branch.

Configuring JIRA to track workflow for maintenance branches and releases

• Megan is working with Peter to improve our ability to track workflow in JIRA. She wanted our thoughts about this.
• Peter seems to have put a new field in place for JIRA views, called "Status for 2.4.x"
• this seems a little too specific, as you'd have to have one for each version
• it would be better to have a more generic field simply for specifying the version, which could be used for any maintenance branch
• what's really needed is to disambiguate the "Fix version(s)" field. Right now that can either mean "intended fix version" or "version where this was actually fixed," depending on whether it's been resolved or closed appropriately.
• A new field called "Intended version" or "Target version" sounds like a better answer

Issues for 2.5.0

• we were initially talking about minimizing UI changes for 2.5, but now we're entertaining this pop-up idea. Is that too much?
  • not really. We'll just adopt a strategy of having the new bits off by default, but available for enabling through sakai.properties or tool options
  • we should, however, try to halt the scope increase now. We're only two months from the next code freeze, and still trying to work on 2.4.x issues
• we haven't yet taken on the file-picker helper issues we had earlier planned to
  • the basic problem: design issues oriented around user expectations for adding attachments to things, and consistency between two different ways of adding attachments (namely, attaching by linking and attaching by copying.)
  • we need to give some design attention to this, but really need to move on it fairly soon, and set some deadlines for ourselves
• still mostly looking at design issues

Proposed Deadlines for 2.5.0

• Resources tool feature freeze: July 15
  • this will be for settling on the scope of any UI changes we'll consider for 2.5
  • probably no more than the pop-up idea IU is floating, but we'll give ourselves a week to think it over and get additional input
• File-picker feature freeze: Aug 1
  • for settling the scope of any file picker (attachment helper) changes
  • need a little extra time to think through this one, as user expectations are a little murky
  • we'll have a focused meeting about this next Tuesday at the same time (4 p.m. GMT, 5 p.m. BST, noon EDT, 9 a.m. PDT)
• Specification freeze*: Aug 15
  • final designs/specifications for what will be completed for 2.5
  • this will be surfaced to the community as what they can expect to see in the release
• Code freeze: Sept 15
  • changes delivered in a working state (i.e. tested to a first order)
• String freeze: Oct 1
  • we may not need this, but any message bundle work will be finalized by this point
• Branch freeze: Oct 15
  • target for the release as a whole
• Release: Nov 1
• Action Item: Clay will call a meeting of the full Resources WG next week in hopes we can adopt these proposed deadlines for 2.5.0

Dublin Core

• There was some comment that this had gone missing. Are we getting it back?
• The UI is already back, and there is some additional work underway, but in short: yes. Jim is doing this.

Should we have regular meetings?

• there is enough work going on, and enough separate threads that need coordination, that we should meet regularly for the next month at least.
• short, frequent meetings are easier to commit to, and probably healthier for the process
• Action item: Clay will arrange/coordinate meetings