Child pages
  • 09_03_2009 Evalsys Team Meeting (Sakai Bridge 002)
Skip to end of metadata
Go to start of metadata

09_03_2009 EVALSYS Team Meeting


- Sean DeMonner, U-M

- Jim Eng, U-M

- Rick

- Stephen

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)
            - (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: to create a linked Jira feature request to expand search) widget; Ellen to create linked Jira feature request to add Group ) to turn on and off the Admin widget) 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?

Action Items:

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.

  • No labels