06_17_2010 Denver Sakai Conference BoF

Owned by Former user (Deleted)
Last updated: Nov 29, 2010 by Former user (Deleted)Version comment
6 min read

06_17_2009 Denver Sakai Conference BoF

Notes http://typewith.me/rN96pc2gJ3

 Sakai 003 Conference Bridge for 11:45-13:00 MDT (GMT-7) on Thurs 6/17:
            Telephone: +1-812-856-7060
            Internet:156.56.240.9
            Conference Code: 22386#
            PIN: 72524# 

 Can anyone record and post audio for this session?

Attendees:

  • Sean DeMonner, U-M
  • Lovemore Nalube, UCT
  • Stephen Marquard, UCT
  • Jim Julovich, IU
  • Nicola Monat-Jacobs, Longsight
  • Jim Eng, U-M (remote)
  • Dick Ellis, U-M (remote)
  • Aaron Zeckoski, unicon (remote)

Agenda:

0. Introductions

1. Updates on local branch merges and next tag/QA cycle

  • U-M merges (target to complete Production system by end of Summer; continue merging in Fall)
  • UCT
  • UMD
    • Hierarchy work pending from Maryland?
  • Merges from other institutions?

2. Getting to 1.2.2 (what should be included, timelines, etc....)

  • Proposal for maintenance branch(es) and releases from branch
  • Need to align with Sakai 2.8, Sakai 3?
  • UI refactoring for/after 1.2.2 tag?
      • Usability issues, particularly of admin interface?
        • Evaluation Admin is a desirable feature for smaller, more distributed schools
        • Cape Town has made some enhancements to UI; Ellen (UMD) to check QA 6 and report out
  • Feature freeze date (Oct 1?) & QA period, resources
  • Need technical/merge coordination meeting?

3. Specific issues/Jira discussions

4. Other items:

  • EVALSYS on QA6: http://qa6-us.sakaiproject.org/portal
  • Work on Confluence to organize feature sets & documentation
  • Progress on product/project management  coordination effort?
  • Conference planning: Presentation / BoF?
    • Sabrina to start top 10 questions and gather
    • Charles: need to identify basics concepts and questions that need to be answered before using the tools
    • Ellen: willing to organize a webinar

Action Items:

Notes from typewith.me

Notes from EvalSys BOF:

Participants:

Sean from UM
Jim Julovich from Indiana
Leah Bergman from U Dayton
Paul from U Dayton
(skipped a few)
Sara Chambers from IU
Karen Watkins from IU
Angela White from UCB
Lovemore Nalube from UCT
Matthew Jones from UM
Jon Hays from UCB
Stephen Marquard from UCT
Nicola Monat-Jacobs, Longsight

Remotely: Aaron from Unicon, Ellen from UMD, Rick from UMD, Jim Eng and Dick Ellis from UM

Sean: key issue is multiple branches which continue to diverge. How are we going to bring them back together again, and when? Last year tried to pool resources to get a QA tag, etc. We don't have anyone actively in a leadership role for the group, causing us to continue do our own things. Hidden agenda (not any more!) that new participants may help us co-ordinate what we're doing.

Branches: UMich - Has been on a branch from trunk for about 2 years
UCT - Has just branched into a local branch but doesn't want one anymore

Longsight has a few but not in a branch. UMD doesn't have a branch (yet).

Stephen:

  • "Current assumption that trunk is always stable or usable"
  • Need to move to similar system as other sakai projects with maintenance branches and releases.

Jim J: How can we get to centralized planning and leadership?

Stephen: What types of leadership and co-ordination resources do we need?
1. Technical leadership (code review, merge reviews, responsible for trunk)
2. Project co-ordination and management (e.g. meetings, QA'ing, doing releases)
3. Product development (features, documentation, UI)

Technical leadership

Aaron: still involved through Unicon but dependent on specific client engagements. Can provide input on stability, code evolution but Unicon doesn't actually run it. Needs people with skin in the game to ensure that it's technical stable. New features going in after 6 months, but after that tool may be reaching maintenance phase. Need for back-end technical leadership and front-end leadership.

Sean & Stephen don't agree with "we've reached feature completeness" idea! Puts burden on new adopters to step up and pay for / contribute new things they want. Could contract Aaron through Unicon? Need to avoid having Aaron as a bottleneck.

People with some knowledge: Jim Eng, Lovemore, Rick. Needs one more person to understand entirety of background, working with Aaron on knowledge transfer. Avoid single point of failure.

Jim J: We can't talk about being in maintenance mode until we have a solution for hierarchy. At least 2 divergent views (UMD and IU working on it). Longsight (Nicola) - has done modification to more fully implement it.

Proposal: Apache-style PMC for code changes to trunk (technical leadership). Members have veto power.

Aaron: doesn't have time to arrange it. Happy to help with knowledge transfer.

Nominations: Jim Eng (UM), Aaron (Unicon), Rick (UMD), Lovemore (UCT).

Output of the team: features that go in should be sent to the list as individual emails. Preferably before but definitely when the feature goes in.

Project co-ordination and management

Alignment issues, QA. Hasn't been a tag for a while because there hasn't been a QA effort. Different institutions exercise different parts of the code.

Do we need to figure out QA before we can move forward with releases?

Aaron: a QA resource or two from institutions that depend on this to develop a test plan which is comprehensive rather than institution-specific, and as new features are released, the QA resources can keep the test plan up to date. Test plan is comprehensive defn of what the tool actually does, and if everything in the test plan is working, we can safely do a release. Reluctant to cut tags without understanding what the tool does and whether it does it properly.

Vote for getting QA figured out. Steps:

  • How is everyone using this?

Resources volunteered for QA:

  • Longsight can find out how their clients are using the tool.
  • Ellen from UMD will help put together QA plan. In process of hiring analyst who would replace Ellen.
  • Michigan will set up a nightly/trunk QA instance (Matt Jones).
  • Course Evals trunk is building on builds.sakaiproject.org (Hudson instance).
  • Oregon Health & Sci Univ. (John Ansorge would lead from OHSU, would include other staff)
  • Selenium tests for UI (Lovemore, Norhal from UM)
  • If IU proceeds from pilot, then would participate (Jim Julovich)
  • Nicola pending approval from Longsight volunteers to be QA lead
  • Ellen would act as fallback if Nicola is unavailable.
  • May be able to take advantage of local test plans (contributed by UCT, UMD, etc.). Aaron will review.
  • UM: load-testing
  • (Adam Marshall <adam.marshall@oucs.ox.ac.uk> previously sent an email saying they'd "definitely like to be part of the QA process."

Other co-ordination:

  • Have a quarterly call. Who would organize / convene that? (reserve bridge, draft agenda)
  • Nicola volunteers.
  • Everyone else needs to respond, engage, consider agenda, show up for discussion.

Product development

Important but other 2 are higher priority.

UI aspects: long list of complex admin options, institution-specific options. Suboptimal - easy to make a mistake. Redesign admin UI with rational grouping of features, ability to toggle / group institutional-specific settings (e.g. don't have to know what "UofM settings" means).

Ability to devolve settings (e.g. with hierarchy), e.g. some settings under control of department rather than institution: more than one level of control. UMD looking at this - next phase of hierarchy deployment.

Need to rationalize the plan for hierarchy. What's the conflict? Needs a feature-specific discussion?

Different concern from overall usability of the tool. From UM perspective, project has been very expensive (released to production before ready, performance issues, business process became tail that wagged the dog, derailed other priorities) - looking to minimize continued investment. Know how to use the tool that there is. UM contribution: continue to do load-testing.

Are people concerned about rationalizing the "runaway admin interface". Nicola: agrees. No other tool in Sakai has central admin panel, but it's not exactly clear as-is. Logical groupings NB, improve descriptions, unpackage site-specific improvements (what are you turning on?).

Who cares about it enough to help improve it? Falls under general concept of UX. Haven't had a lot of UI types to date - their experience could be helpful in admin panel but also elsewhere.

Initial design was relatively clean but has suffered from the entropy problem. Started good, diverged.

More significant for sites with dept-level administrators, i.e. are people using hierarchy more dependent on good UI? UMD still defining functional requirements.

Aaron: only admin-equivalent users (or evaluation administrator, institution-wide) would see admin panel.

Jim J: Looking at it holistically, super-user vs dept level, the dept level does not need much input into pushing out the surveys. They need to select classes, edit questions in templates, publish evaluations. Beyond that giving them too much control is dangerous.

2 separate functional areas: large control, small control.

UCB is awaiting impending mandate, but once that happens may be able to dedicate resources at several levels. UCB does have designers, committed to Sakai 3 so could be new designers.

Sean from UM: if new adopters want to see improvement in UX, figure out how to get it done.

EVALSYS-888 assigned to JIRA for followup (see notes in JIRA).

Email handling etc. (EVALSYS-689) - probably fixed in trunk but we need a new release.

We should tag a release soon as a beta so there's a reference point. Nicola will look at the Longsight revision being used.

Nicola will follow up with Sabrina Crawford re top 10 questions.

Charles (Chuck Hedrick) from Rutgers - followup? Chuck did email Ellen the general concept/questions

Ellen will aim to host a webinar in the future (overview of the tool).