Calls are currently taking place on Wednesdays at 11:30 AM EST (New York, USA) each week.
- The Conference Bridges support both Internet (e.g., Polycom, XMeeting (for MacOS), Ekiga (Linux, Windows)) and telephone connections:
- Telephone: +1 812 856 7060
- Internet: 126.96.36.199
- Conference Code: 386#
- PIN: 72524#
Participants: Janice Smith, Mathieu Plourde, Sean Keesler, David Goodrum
- The OSP Community is using Action Verbs to describe needs for Sakai 3.0:
- New task force to focus on Requirements
- Focus on T&L
- Cultural divide between Developers vs Users
- Sakai 3 is our opportunity to build features in the core services
- We could try to consolidate current Jira feature requests...
- Global requests get buried in Jira
- The OSP Community documents and approves enhancements to the community code via the following process:
- These OSP docs are being considered as a possible template by Clay, product council
- Faculty members may have crazy ideas, those ideas should be implemented at some point...
- Michael K. in a post had suggested getting 20 faculty from 20 institutions to post short descriptions of needs/ideas
- Bias from the fact that ideas come from users
- Institutions are not putting a lot of resources to shape the future, focus on local short term issues.
- LMSs have always focused on faculty and students, administrators have been ignored.
- Meta-work should be included.
- Sakai would be easier to sell, since it would target the people who have access to the wallet.
- Gathering feedback sets expectations that cannot be met by smaller institutions.
- Have to find allies in the community.
... So, what's next?
- Is there a timeline?
- What is our process?
- We need to step in right away.
- David has already worked on a very rough visioning Excel doc -- a rough stab at mapping T&L needs to capabilities and functional visioning. Needs feedback. It's linked from this pageon A Community Process for Requirements Gathering that was started by Josh Baron.
- We have to nail down our vision in something that will get buy-in from the Developers.
- Design is a process, we need to work in tight loops instead of in a vacuum.
- We need to chunk the bigger task in sub-tasks that are achievable. This expertise is not easy to find in the community.