MATSim Committee

The Role of the Committee

The MATSim committee serves as an entity to decide upon strategic decisions, mostly regarding the source code of MATSim. The committee collects topics and questions about the software design of MATSim and tries to decide upon and answer them regularly. The decisions are then presented to the MATSim community. A few stakeholders have Veto power, should they be unhappy with the committee's results.

In addition, MATSim Committee members are made administrators on GitHub for the MATSim project, so they could officially represent MATSim to GitHub in case of problems. With a similar thinking, MATSim Committee members get a log in for MATSim's build server so they could re-start builds in case of problems or look at configuration details by proxy for their institutes' MATSim developers (Marcel will still be the main responsible for the build server, but in case he's not available on short notice, other committee members should have the opportunity as well to interact with the build server).

 

Committee Members

In general, we try to include one person of each major contributing institute into the committee.

Currently, the MATSim committee consists of

  • Marcel Rieser, senozon
  • Michael Zilske, VSP, TU Berlin
  • Thibaut Dubernet, IVT, ETH Zurich
  • Johan Joubert, University of Pretoria
  • Gregor Lämmel, DLR Berlin
  • Pieter Fourie, FCL, Singapore

Decisions by the committee need approval by the following people with veto power:

  • Kai Nagel, VSP, TU Berlin
  • Michael Balmer, senozon
  • Francesco Ciari, IVT, ETH Zurich

 

Committee Work and Meetings

After a successfull start in 2011, the committee work got a bit lost in 2012. In the summer of 2013, a fresh start was taken by defining the following, rather informal rules for the work of the committee:

  • The committee collects issues in MATSim's issue tracker. Typically, issues for the committee should be assigned to the user "MATSim Committee" available in the issue tracker (Direct link: All open issues assigned to committee).
  • 2 times a year, the committee decides upon the collected issues. It uses for this the comment function of the issue tracker.
  • By default, the 2 times should at the developer meeting, and about 6 months away from it.
  • The community is informed about the decisions by an email to the developers mailing list.
  • Each time, another committee member plays the organizer to push the other members to answer the decisions, to collect the decisions and to send the email informing the community about the decisions.

The limitation to 2 times a year is a requirement to allow the committee to thoroughly discuss the topics, while allowing the committee members to organize their work load in an appropriate way. Implicetely, it also underlines the fact that the committee is responsible for strategic, long term decisions which should not be rushed.

Committee reports

Committee reports since 2013 are collected here.

Earlier committee reports are available at our archived old website.