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.
This could be a wrapper for the logtool that uses the existing Visualizer
Needed as a foundation for an Electric Vehicle model
Example is the MinneTAC experiment manager. This could probably be constructed as a stripped-down version of the tournament scheduler.
This needs to be a major thrust of our preparation for the 2012 competition.
Example is the SCM tournament scheduler. Must include agent registration.
Example is the MinneTAC experiment manager. One possible tool for this is jenkins
When folks are watching games and tournaments, what can we show them about the relative performance of the agents?
The goal is to complete this work by the end of October 2011.
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.
Presumably this will be done using a Jenkins installation currently being set up at Minnesota.
It's after the server has started, and before the clock starts. Brokers log in and get their initial game data.
It's somewhere after the clock has started. Brokers publish new tariffs, expire existing tariffs, and revoke tariffs.
Complete on 7 March 2011.
It's the beginning of the game. The default tariff is composed and published, presumably by the default broker.
It's the beginning of the game, before brokers are connected. The customer models start up, and get subscribed to the initial default tariff.
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.
The server supports a web page through which the log can be viewed.
Some tariffs have been published. Customers evaluate their options, and some decide to switch subscriptions.
Accounting receives transactions, runs the account updates, and forwards completed transactions along with updated account status to individual brokers.
Customers run their simulation model at the beginning of a timeslot, and report the results through their tariff subscriptions.
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 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.
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.
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.
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.
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.
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?