Meeting Minutes 20100614

= Meeting Minutes =
 * Meeting: TAC Energy Developer Online Meeting
 * Date: June 14, 2010, 5.30pm CEST
 * Participants: Carsten Block, John Collins

= Agenda =

Technical infrastructure (10 min)

 * 1) Development Language & Framework (Groovy, Java, Python)
 * 2) Issue & Task Tracking, Code & Release Management (launchpad et al., hudson, ...)
 * 3) Public Wiki for public documentation & idea discussions (Media Wiki,...)
 * 4) Mailing Lists / Community communication

Development Roles & Procedures (15 min)

 * 1) Which "formal" development roles do we need (Code Lead/Gatekeeper, Developers, Testers, ...) and who does what?
 * 2) Which subprojects do we have that can be developed in parallel (Server, demo client, graphical client, game archive/ controlled server)
 * 3) How do we scope releases (fixed features sets vs. fixed timeboxes)
 * 4) Definition of Done, Coding Standards
 * 5) Role of Testing & Beta Tester Feedback

Big Picture Planning until Release 1.0 (20 min)

 * 1) Prioritization of "major" release milestones until v1.0 release
 * 2) Planned v1.0 release date
 * 3) Desired "high level" feature set for v1.0
 * 4) Prioritization (Required Server Features for v1.0, demo client(s), ...)

Diverse (10 min)
= Results =

Technical infrastructure

 * Programming Languages & Frameworks
 * The Java Enterprise / groovy / grails infrastructure will be kept for server development
 * For client development we will use different platforms for different clients (e.g. simple java / groovy based client for programmers + repast based graphical client...)
 * The different market / negotiation / tariff components should be developed in a way that they can be easily refactored into plugins in future, in order to allow a flexible adaptation of the competition's market rules
 * A demo client for programming oriented participants should be provided. The demo client developed at http://launchpad.net/tacenergydemo can serve as a basis for this.
 * A demo client based on Repast should be developed, which leverages the "graphical programming" capabilities of Repast framework to allow easier access to the competition for non-programmers. This could probably be done, for example, by exposing the server interface as a set of pre-defined agents in the Repast environment.
 * We will continue to use the already existing launchpad infrastructure (http://launchpad.net/tacenergy and http://launchpad.net/tacenergydemo) for


 * bugtracking
 * requirements tracking (called blueprints in launchpad)
 * code management
 * version management
 * release management


 * Wiki usage
 * A public wiki at http://tacenergy.wikia.com/wiki/TAC_Energy_Wiki will complement launchpad and will provide, for example, getting started guide, detail discussions about launchpad blueprints, etc.
 * The access restricted RSM wiki / svn will continue to serve as basis for paper projects, proposals, personal contact data of team members, etc.
 * The Hudson continuous integration server at http://ibwhudson.iw.uni-karlsruhe.de will continue to serve as CI Server for TAC Energy.


 * Each subproject should have its own hudson job


 * In each subproject hudson should automatically
 * compile a binary (e.g. a war file) of the subproject
 * run all existing unit and integration tests and report test results
 * run code coverage based on cobertura to easily show classes are covered with tests and which are not
 * generate a zip file of the source code
 * generate a zip fole comprising the sub project's documentation (if applicable)
 * Community & Developer Communication
 * We use the combined public forum / mailing list at http://tac-energy-users.771212.n3.nabble.com (also integrated into tacenergy.org at http://ibwmarkets.iw.uni-karlsruhe.de/tacenergy/user-list.gsp) for community communication. Interested persons should be encouraged to sign up to this list. Here questions on how to use TAC Server or clients can be asked and should be answered by TAC Energy team members. As soon as bugs or improvement requests are identified within these discussions the original reporter should be encouraged to create a corresponding bug report / blueprint in launchpad
 * We use the combined public forum / mailing list at http://tac-energy-developers.771202.n3.nabble.com (also integrated into tacenergy.org at http://ibwmarkets.iw.uni-karlsruhe.de/tacenergy/developer-list.gsp) for communication in the developer team. Like this, future team members have easy and convenient access to archived discussions. The list is merely focused on reaching all developers to initially discuss new ideas, to set-up meetings etc. As soon as more detailed discussions pertaining to blueprints (features) or bugs start, these should be shifted to launchpad and / or wikia wiki.

Development Roles & Procedures

 * We use a gatekeeper approach (see Launchpad guide slide 16-17) to manage code.
 * Carsten will initially take over the role as gatekeeper for the server code branch
 * John will initially take over the role as gatekeeper for the client code branch
 * Identified Sub-Projects
 * Demo Client for "computer science participants" (code oriented)
 * Demo Client for "management science participants" (mostly graphical based on repast)
 * Dedicated Competition Visualizer that runs independent from the server by intercepting queue server messages
 * Competition Data Archive (OLAP data warehouse)
 * Control Server for repeated competition simulations
 * Single Sign-On Infrastructure (based on LDAP)
 * Scoping of Releases
 * We use fixed timeboxes for releases
 * At the beginning / end of each release features & bugs to address in the next release are jointly (re-)prioritized and scheduled based on the experiences of the previous release, user feedback, etc.
 * Definition of Done, Coding Standards
 * Carsten adds Definition of Done to wikia wiki
 * John adds MinneTAC Coding Standards to wikia wiki
 * Role of Testing & Beta Testers
 * We want to follow a test-driven design and development approach
 * We would love to have Beta testers that already try to develop an agent during the course of the development of server and demo agents. Their feedback is valuable input for task scheduling, bug identification etc.

Big Picture Planning until release 1.0

 * Targeted release date for v1.0 of game server, demo client, and game specification: November 1st, 2010


 * Milestones
 * Milestone 0.7: Execution Phase implemented and running (Due: June 30th, 2010)
 * Milestone 0.8: Tariff publishing & subscription functionality including market intelligence service implemented and running (Due: August 31st, 2010)
 * Milestone 0.9: Contract Negotiations implemented and running (Due Oct 31, 2010)
 * Feature set in v1.0 release on Nov 1st, 2010
 * Fully functional server that works "stand-alone" (integrating visualization, user management, etc. such that it can be easily deployed by competition participants and run as a single application on a tomcat server for local testing purposes)
 * Fully functional demo client dedicated to the computer science audience (i.e. no graphical programming support)
 * Complete Technical game specification based on http://www.tacenergy.org/docs/latest/manual/index.html
 * Complete formal game specification (similar to http://www.sics.se/tac/tac07scmspec.pdf)
 * Important features that will be implemented after  v1.0 release but before first competition takes place in Summer 2011
 * Single-Sign On infrastructure (LDAP based)
 * Separate Competition visualizer that intercepts queue messages and thus reduces core server load during public competition runs
 * Business Warehouse (OLAP based, e.g. http://mondrian.pentaho.org/) for historic competition data archiving and data mining
 * Undecided features
 * Graphical demo client based on repast

Other

 * Next online Skype meeting: Friday, June 18th or Monday, June 21st
 * Tasks for next meeting:
 * Define milestone release dates
 * Schedule blueprints
 * Assign development tasks

= TODO =
 * John: Setup wikia wiki base structure according to MinneTAC wiki structure - done.
 * John: Add more blueprints concerning several issues that have been discussed before (e.g. competition archive) but that have not been written down (?)
 * John: Add MinneTAC coding standards to wiki
 * Carsten: Add definition of done to wiki
 * Carsten: Migrate scrumy.com taskboard to corresponding launchpad blueprints
 * Carsten: Provide definition of done in wiki
 * Carsten: Write blueprint for competition self scheduling as an example on how to connect launchpad and wikia