Sakai Weekly meeting reminder

[Barbara Glover]

hi all
Just a reminder that we have our weekly Sakai UX meeting today at 2pm  
PST/ 5pm EST

Agenda

     * Anything further on:  Michael Korcuska's requirements proposal??
      * new items on the Sakai UX Issues and Discussions list
     * update on Pager: user testing results
     * update on Design Patterns

See you there.
Barbara

Past meeting notes below.

2008-02-20/21 at 23:00 UTC time (3pm PST/6pm EST/8am Sydney)

Facilitator: Tim
Note taker: Daphne

Conference Call Info
Dial-in #: 812-856-7060
Conference ID: 350 #
Pin: 72524 #
Agenda

     * Discuss Michael Korcuska's requirements proposal:
           o blog entry: http://sakaiblog.korcuska.net/2008/01/18/ 
product-management-in-sakai/
           o wiki page: http://confluence.sakaiproject.org/confluence/ 
display/REQ/2008+Proposed+Product+Management+Process  (PLEASE READ  
PRIOR TO MEETING)
           o Process vision as well as product vision
     * new items on the Sakai UX Issues and Discussions list
     * update on Pager: user testing results
     * update on Design Patterns

Next Steps:
Meeting Notes

Present: Allison, Daphne, Colin, Shaw-Han, Barbara, Tim, Michael K.,  
Mike E.

Discussion of requirements process

     * 6 months is not a lot of time for larger, highly coordinated  
work (multi-institution)
           o Michael: roadmap in phases would be a good goal -  
fuzzier for longer term that gets less and less fuzzier. Michael will  
clarify.
     * How do we get UX issue into the process?
     * How do we make sure that needs assessment and UX review can  
play into this process?
     * The spreadsheet of UX issues (both contentious & obvious  
agreed upon) - what's the best way to get these into the plan?
     * Micheal: views this process as what work is going to get  
resources attached to it. how do we get our arms around what  
significant projects are underway.
           o Some UX issues may be projects in themselves. How do  
they get considered in the gathering of ideas for what will be worked  
on?
     * Leverage current project work - resources.
     * Hard because is so cross-cutting (ex. Site action)
           o Good example since everyone would like to see this  
changed but no-one wants to take it on themselves. Michael: hope this  
process will help find folks willing to put some resources toward  
this and work together.
           o Who "owns" the follow-on work? So site action gets fixed  
and then we need additional work done, who does it?
           o Difficult because pieces of code are owned by  
institutions in Sakai rather than by individuals (like an Apache  
mode). The idea of an institution owning a piece of code relies on  
the people that worked on it. We need to figure out how to enable  
more people in the community to work on pieces of code rather than  
relying on one person. More documentation perhaps? Other ideas?  
There's a real balance about how much documentation we want to write  
versus getting work done. Is there a way to build some of this  
"transfer of knowledge" into the code itself (thinking agile & code  
writing standards (taught in java classes))
     * Product Manager would have a responsibility to gather UX  
issues from us and help us get our ideas presented the "right" people  
(who's working on it or interesting in it, what's the best way to get  
their attention)?
     * What do people think about the idea of this committee made up  
of people who have contributors? Needs to be relatively small to  
function. That means lots of people are left off. Is that OK? Are  
there others ways to do it?
           o Contributors rather than just developers.
           o People working on something that goes into the release  
from requirements to design to development to QA.
           o Need to make sure a larger group is represented. As long  
as the smaller group represents
           o What about allowing the community to elect? Could be a  
long drawn out process. Perhaps select the initial group and them put  
this process into place moving forward.
     * Perhaps the board could initially select? Have clear criteria  
for how they would choose the people on this committee?
     * Needs to include a diverse group of perspectives
           o How broad is the mission of the group? Michael: OSP  
community has sort formed this kind of group already. I could see the  
function of this group to be similar for collaboration and teaching &  
learning. Perhaps those 2 groups get separated out down the line when  
there are more resources to think about.
     * Like the idea of have a larger overarching view rather than  
current tool-centric view.
     * Not necessarily address the important concern of more cross- 
institution collaboration but hope that the person that plays the PM  
role may be able to identify institutions
     * UX Lead (Nathan) has a voice into the process but isn't  
probably a product manager in the sense that it's defined here. Still  
don't know if the UX role is a project or position at this point.
     * Think of this role as similar to what Peter does with project  
coordination plus some. So he may get some activities removed from  
his plate and others.
     * How do the requirements get defined? Almost like the step  
before this process where we can give input and provides insight  
based on user research.
           o Problem we've been challenged with. The way we've had  
input in the past is when we hear someone is working on
           o Not about getting people to work on stuff that we want  
to get fixed. But may help us know about work that is happening and  
allow us to plug ourselves in and help out.
           o May provide more stability about what people will be  
working on. And will lend itself to increased collaboration.
     * Isn't a process that allows our definition at the level of  
functionality in a tool to what is a tool like OSP for.

Note taker rotation: Allison, Barbara, Daphne, Eli, Erin, Jackie,  
Judy, Julie, Kathy, Shaw-Han, Tim, Will
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20080227/9f273be5/attachment.html>