2009-09-30 Product Council Meeting

Owned by Former user (Deleted)
Last updated: May 14, 2010Version comment
3 min read

Phone number: 1 (812)856-7060
Internet: 156.56.240.9
Room code: 348#
Password: 72524#

Agenda

  1. Review Incubated Projects
  2. Case Study of Forums changes for 2.7

Incubation Documentation
Development Efforts formally considered

Attendees

  • Stephen Marquard
  • Noah Botimer
  • Max Whitney
  • Clay Fenlason
  • Nate Angell
  • Eli Cochran
  • David Goodrum
  • John Lewis
  • Michael Korcuska

Minutes

Formal Acknowledgement of Incubation:

  • Worth marking formally that these projects are in incubation when they come in.
    • Want to see an official list. One authoritative location.
    • Good for communication as well.
  • At least some clear sign that the documentation submitted is sufficiently complete.
  • Communicating new entries.
  • Would be helpful to organize the items by broad functional category, and not just a big laundry list.

Comments/Questions raised in reviewing currently incubated projects:

  • Maintenance team would give opinions about maintainability of code. The fact that there is currently only one developer may or may not be a problem if at the end of the day it's maintainable.
  • For many of these projects, quality UX is key to its success, yet they have not been design-led and are not resourced with UX skillsets.
  • What can the Product Council do to encourage and support this?
  • Active UX talent is in short supply in the community; On the other hand, heuristic analysis doesn't take much time. User testing requires more commitment.
  • Need to at least raise UX as a flag - something the project team should be taking into account in its plans.
  • Hard to get people to refactor teams when the projects are already far along. Short of UX reviewers, can we get a checklist process that people could use?
  • Fluid has a heuristic walkthrough protocol. Also user testing protocol, and accessibility.
  • In the Sakai 2 world need to strike a balance that is not unreasonably disruptive.
  • Need to reckon this against what they will replace. If they are a big step forward that should count for a great deal even if the design is less than ideal.
  • Yes, but in some cases the step forward may be too big, and the design reconsideration would not send them back to the drawing board so much as asking them to rein things in or trim them down.
  • Groups work is important because the initial designs out of UX initiative largely ignored them.
  • Part of groups project is the exploration of some ambitious ideas, but perhaps this exploration should be separated out and left in R&D, and incubation should be limited to those portions marching toward a release?
  • Limited in what we can say about joining groups to other Sakai 3 projects when there aren't any other Sakai 3 projects in incubation. Groups is it for now.
  • May want to clump and cluster these by types of activities
  • In Sakai 2 the group model didn't flow through to capabilities in a consistent way. Perhaps deliverables should include articulated expressions of how they may be leveraged by other capabilities.

Forums Case Study:

  • Some history: longer-term enhancement to the system, a merging of several streams of work, and some confusion about commitments and responsibilities.
  • The trouble is that there have been new features and incompatible branches without much change in trunk for nearly a year now. In this way the development process around forums has diverged from standard practice. Been too much focus on engineering improvements rather than managing it as a whole.
  • Without management-level involvement, problems going to get worse.
  • PC needs to foster that approach to managing projects. Need project team operating effectively, not just fixes and features.

Next Steps

  • Clay will send out a communication about projects in incubation, and work at improving organization in Confluence.
  • Eli will help Clay pull together UX testing protocols (from Fluid) to help guide new projects