Time: 10:00 AM Eastern US (contact MichaelFiedler if you'd like to participate)

The Automation meetings alternate times each meeting to accomodate the global team.

Agenda

* Reoccurring agenda items:

• Recap of previous meeting AutomationMeetings20111110

* Main agenda items:

• Previous Action Items:
  • Agent/Actor registration scenario
    • CharlesRankin, MaxVohlken, PaulMcMahan and MichaelFiedler met on 28 November to discuss
    • Discussion acknowledged the general validity of the actor registration scenario, though not applicable to all automation providers
    • Concern that putting this in the V1 spec would raise the bar too high for implementers
    • Agreement to table the scenario for V1 and bring it back for discussion in V2
      • Workgroup members from the test domain will likely prototype/early implement something in this area
      • Present it back to the workgroup as a proposed basis for a spec in V2
      • Alleviates concerns that any non-OSLC specified work in this area is not likely to be "throw away"
• Discuss Automation Result contributions
  • See "Updating Results and creation of contributions" in AutomationScenarios
  • See the spreadsheet at ResourceDefinitions for work done last year in this area
  • What are the scenarios around results and contributions?
  • What attributes should results and contributions have?
  • Are contrtibutions a unique resource type?
• Plans for moving from scenario development to spec development
• Next meetings:
  • 8 December

Minutes

Attending: Michael Fiedler, John Arwe, Max Vohlken, Robert Elves, Sheehan Anderson, Rich Rakich, Pete Steinfeld, Charles Rankin, Paul McMahan? , Barys Dubauski, Pramod Chandoria, Thomas Spatzier, Vaibhav Srivastava

* Reviewed Agent/Actor registration scenarios

• No major comments from the workgroup
• Paul McMahan? summarized the concerns around making sure any early work in this area would not be wasted.
• Issue is now resolved, agreement is that agent registration scenarios are out of scope for the initial spec

* Discussion on automation results and result contributions

• Result identifiers - how do consumers find the "latest" result
  • Brief discussion on desirability of monotonically increasing identifiers
    • not something which should be in the spec - up to the provider
  • agreement that some combination of dc:created and the proposed "started" and "ended" attributes could accomplish the scenario
• Automation contributions - unique artifact? or included in the result?
  • Expectation of a consumer doing a GET on the result: contributions included in the result? or links to contribution artifacts?
  • If separate, how is relationship to result modeled?
    • Contributions seem to be dependent children of results, not standalone entities
  • TODO: Follow up discussion to drill down on contributions and results. MaxVohlken, CharlesRankin, PaulMcMahan, PramodChandoria and VaibhavSrivastava will participate. Contact MichaelFiedler if you would like to participate.
• Need to document a scenario illustrating how consumers might view results differently. Example:
  • Build runs and completes successfully
  • Subsequent testing shows the build to be "bad"
  • Verdict for the build is still "success" while a test contribution to the result would have a verdict of "failed"
  • Consumers bear some responsibility in how the quality of an automation result is interpreted.

* Discussion on how persistent/transient automation artifacts are

• Consumers should make no assumptions. Should be prepared to handle dead/moved links (HTTP 404, 410, 301 scenarios).

* Workgroup housekeeping

• Next meeting: 8 December at 1PM Eastern US. Primary topic will be deployment scenarios
• Goal to have 15 December meeting be a review of updated artifact attributes