09_03_2009 EVALSYS Team Meeting
- Sean DeMonner, U-M
- Jim Eng, U-M
0. Context and Boston follow-up
1. Review of proposed U-M merges (see excerpt of earlier message from Jim Eng below; please *preview* the proposed changes before the meeting)
- http://tinyurl.com/nv62l2 (screencast of U-M changes for context)
- monthly review of proposed changes
- document proposed changes in Jira & send email to evaluations email group for comment
- add more descriptive detail to each tag
- reviewed Jiras from U-M merge:
http://jira.sakaiproject.org/browse/EVALSYS-769(Stephen to create a linked Jira feature request to expand search)
http://jira.sakaiproject.org/browse/EVALSYS-767(Instructor widget; Ellen to create linked Jira feature request to add Group )
http://jira.sakaiproject.org/browse/EVALSYS-788(Ability to turn on and off the Admin widget)
http://jira.sakaiproject.org/browse/EVALSYS-787(Ability to turn off links that might trigger long-running queries, Ellen to create linked Jira feature request to add Group ))
- Jim to send out list of pending Jiras
2.Tactical questions for joint discussion/decision
- There's been recent mention of tagging eval-1.2.2. What should be included, timelines, etc....
- The ability to import/export institutional specific scales/items/etc (i.e. customizing the preload). I believe there is a JIRA suggesting an xml format. I've started working on one and I think U-M has as well. Is it worth to standardize this?
3. Pending merges from other institutions
4. Next steps:
- next technical/merge coordination meeting
- progress on product/project management coordination effort?
All: When Jiras are posted send email to evaluations email group
Jim: Send out list of pending Jiras
Sean: Set up next tech review meeting, feature freeze & QA period
Jim: Work on spec of XML import
Stephen: Will work on Confluence to organize feature sets & documentation
On Aug 27, 2009, at 3:34 PM, Jim Eng wrote:
Sorry. I wasn't at the meeting in Boston because I had to leave the conference early. I understood from Aaron that we were to merge to trunk. I have been creating branches to work on particular features. Once all the details have been worked out, I have been merging from there to trunk. I have done this with four features so far. In each case, there is a setting to enable/disable the feature or capability and the default setting makes no change in any behaviors or user-facing components. Here are the tickets that have been merged to eval trunk:
I will be glad to participate in the meeting. If need-be I could back out these changes in trunk, but I would prefer not to. It's very easy for a branch to become stale so it's very hard to merge back to trunk. We believe these are features or capabilities other people will want, so I would prefer to continue getting them into trunk when we are ready to merge them, unless that creates a problem for anybody.