Development Roadmap - Pyosch/powertac-server GitHub Wiki
This page is for building and managing a development schedule that hangs together and helps all of us know what the others are working on. Starting in January 2011, we tried running a 2-week cycle, with specific features/issues assigned to each incremental release, but that effort failed. Here is the original set of milestones.
Therefore, we will try to manage by targeting individual stories. These represent incremental bits of server functionality that cut across the various server modules, with the goal of getting a working server before the end of March 2011. Each story will be summarized here and expanded on its own page, with a list of tickets and people that implement it.
Pending Stories
Repast agent framework
Game viewer for recorded state
This could be a wrapper for the logtool that uses the existing Visualizer
Wind-park genco model
[Storage model](Storage model)
Needed as a foundation for an Electric Vehicle model
Electric Vehicle model
Web app for experiment scheduling
Example is the MinneTAC experiment manager. This could probably be constructed as a stripped-down version of the tournament scheduler.
Genco model driven by real-world bid data, correlated with weather data
Bilateral negotiation between brokers and large customers
Long-term procurement contracts between brokers and gencos
Completed Stories
Java agent framework
New and updated customer models
This needs to be a major thrust of our preparation for the 2012 competition.
Web app for tournament scheduling
Example is the SCM tournament scheduler. Must include agent registration.
Backend server controller for tournaments and experiments
Example is the MinneTAC experiment manager. One possible tool for this is jenkins
Generation and display of tournament results
When folks are watching games and tournaments, what can we show them about the relative performance of the agents?
Update Grails agent framework
Porting to Spring/Java
The goal is to complete this work by the end of October 2011.
Complete state recording
As of 19 September, with the introduction of annotation-based logging, this may be a solved problem. All that remains is to ensure that new state-changing code is annotated correctly.
Automated build/test process
Presumably this will be done using a Jenkins installation currently being set up at Minnesota.
Broker login
It's after the server has started, and before the clock starts. Brokers log in and get their initial game data.
Tariff publication
It's somewhere after the clock has started. Brokers publish new tariffs, expire existing tariffs, and revoke tariffs.
Complete on 7 March 2011.
Default tariff publication
It's the beginning of the game. The default tariff is composed and published, presumably by the default broker.
Customer setup
It's the beginning of the game, before brokers are connected. The customer models start up, and get subscribed to the initial default tariff.
Weather data publication
Every hour, a new weather report is sent to all brokers. Every 24 hours, a new 48-hour weather forecast is sent to all brokers.
Server log viewer
The server supports a web page through which the log can be viewed.
Tariff subscription
Some tariffs have been published. Customers evaluate their options, and some decide to switch subscriptions.
Accounting transactions
Accounting receives transactions, runs the account updates, and forwards completed transactions along with updated account status to individual brokers.
Power consumption and production
Customers run their simulation model at the beginning of a timeslot, and report the results through their tariff subscriptions.
Server initialization
The server starts up, creates some number of timeslots and sets other variable parameters, creates and initializes customer models, initializes server components, prepares for broker login.
Wholesale power sources
Wholesale buyers and sellers operate in the forward market, and potentially in the balancing market. In the market prototype, this role was called "Liquidity Provider" -- it used historical price data to limit prices in the wholesale market by buying and selling.
Forward market trading
Brokers, along with wholesale power providers (GenCos) (and potentially buyers), bid in the forward market across multiple timeslots, the market is cleared periodically, transactions are posted, public information is broadcast to all brokers, and updated positions are routed to respective brokers.
Simple balancing
Customer consumption and production and current-timeslot market positions are summed to determine balance for individual brokers and in aggregate. A simple penalty is charged for imbalance, transactions are run, and brokers are notified of the outcome.
Market-based balancing
Customer consumption and production and current-timeslot market positions are summed to determine balance for individual brokers and in aggregate. Brokers submit bids for their available balancing actions, and the Liquidity Provider submits bids for its ancillary services. The market is cleared, balancing actions are taken as determined by the cleared bids, transactions are generated, and interested parties are notified.
Game completion
After the last timeslot, game summary data is generated and stored, including the winner-determination metrics, and the database is dumped before the server shuts down.
Process
For each item, there must be a ticket, linked to this page, and the issue must be assigned to someone by the beginning of a cycle; otherwise we need to re-plan. The assignments must be visible both on this page and on the individual tickets. To begin with, we'll schedule releases on Mondays, to give us weekends to catch up, and because the end of January 2011 falls on a Monday.
Because we will not always accomplish everything we plan, we should feel free to move items down the list as soon as it becomes clear they need to be moved. However, because we need to be able to evaluate and improve our planning, we should keep track of these changes. Is it enough to have the history in git, or should we include a "deferred items" section for each release?