This wiki is locked. Future workgroup activity and specification development must take place at
our new wiki
. For more information, see
this blog post about the new governance model
and
this post about changes to the website
.
TWiki
>
Main Web
>
CmHome
>
CmMeetings
>
CmMeetings01212009
(22 Jan 2009,
SteveSpeicher
)
(raw view)
---++ Date: Wednesday, 21 January 2009 Time: 12:00 PM Eastern, 9:00 AM Pacific, 6:00 PM Zurich<br />(contact SteveSpeicher if you'd like to participate) ---+++ Agenda: * Introduction of new members * Addition of Accenture to Members link * Call for last minute agenda items * FYI: JSR-328 Change Management API http://jcp.org/en/jsr/detail?id=328 * No affiliation with OSLC CM * Review progress on action items * SteveS to provide a configuration/discovery scenario * SteveA to take a pass as defining generic APIs and resource definitions from existing C/ALM integration work * Carolyn to work with C/ALM product teams on OSLC aspect of support. * Carolyn to work on change requests to requirements scenario (and rounding out the C/ALM scenarios) * Andre to provide additional scenarios used internally within RTC where components need to create work items (and need a good way to handle constraints) * Mik to contribute aggregation of change requests scenarios * Work on scenario elaboration: * Defect Scenario - http://open-services.net/bin/view/Main/DefectScenario * Agile planning of change requests - http://open-services.net/bin/view/Main/CmScenariosAgilePlanningOfChangeRequests * Specification development: * Identify key specification needs from scenarios, develop and assign owners ---+++ Minutes: *Attendees*: Steve Speicher, Steve Abrams, Andre Weinand, Scott Bosworth, Randy Vogel, Gary Dang, Sam Lee, Carolyn Pampino, Tack Tong<br /><br /> *Minutes:* * Introduction of new members: Randy Vogel and Gary Dang * No agenda updates (other than needing to end the meeting early) * SteveSpeicher reviewed this scenario: http://open-services.net/bin/view/Main/CmScenariosConfiguration * Concern was expressed regarding large collection responses in large CQ deployments (250 dbs). This may be mitigated by schema repo -> user db hierachy (not more that 25 in a collection). Key message: always handle large collections: pagination, etc. * Overall feedback was it was simple and seemed workable. Action to all to review and provide feedback. * Specification contribution from scenario needs to occur now. WG members encouraged to contribute. * Next meeting: Feb 4, 12-1 Eastern
E
dit
|
A
ttach
|
P
rint version
|
H
istory
: r2
<
r1
|
B
acklinks
|
V
iew topic
|
Ra
w
edit
|
M
ore topic actions
Topic revision: r2 - 22 Jan 2009 - 02:23:02 -
SteveSpeicher
Main
Main Web
Create New Topic
Index
Search
Changes
Notifications
RSS Feed
Statistics
Preferences
Webs
Main
Sandbox
TWiki
Български
Cesky
Dansk
Deutsch
English
Español
Français
Italiano
日本語
Nederlands
Polski
Português
Русский
Svenska
简体中文
簡體中文
Copyright � by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our
Terms of Use
Ideas, requests, problems regarding this site?
Send feedback