Quick Links:

Releases | Mailing Lists | Source Control | Issue Tracker | Regression Tests

Project Organization

The Jikes™ RVM project is a collaborative software development project dedicated to providing an open source state-of-the-art infrastructure, freely available for performing research on virtual machine technologies for the Java™ programming language. This document describes the composition of the project and the roles and responsibilities of the participants.

Roles in the Jikes RVM Project

There are various roles people play in the Jikes RVM project. The more you contribute, and the higher the quality of your contribution, the more responsibility you can obtain.


Users are the people who use Jikes RVM, without contributing code or documentation to the project. Users are encouraged to participate through the mailing lists, asking questions, providing suggestions, and helping other users. Users are also encouraged to report problems using the bug tracking system. Anyone can be a user.


A user who contributes code or documentation becomes a contributor. Contributors are the people who contribute enhancements, bug fixes, documentation, or other work that is incorporated into the system. Anyone can be a contributor.

The most efficient way to make non-trivial contributions to the project’s documentation (User Guide and other online material) is to edit the sources yourself. If you are interested in contributing in this fashion, please clone our GitHub repository and send us patches or pull requests.

Jikes RVM Team Member

A contributor who gives frequent and valuable contributions can be promoted to a Jikes RVM team member. Team members have write access to the source code repository, and voting rights allowing them to affect the future of the project. The members of the Jikes RVM team are responsible for virtually all of the day-to-day technical decisions associated with the project. They are the gatekeepers, deciding what new code is added to the system. All contributions will be processed by one or more team members before potential inclusion into the Git repository.

A contributor can become a Jikes RVM team member by the following sequential process:

  1. they are nominated by an existing team member,
  2. at least 3 other team members support their nomination, and
  3. the Jikes RVM Steering Committee approves the nomination by majority vote

Becoming a team member is a privilege that is earned by contributing and showing good judgment. It is a responsibility that should be neither given nor taken lightly. Active participation on the mailing lists is a responsibility of all team members, and is critical to the success of the project. Team members are responsible for proactively reporting problems in the bug tracking system, and annotating problem reports with status information, explanations, clarifications, or requests for more information from the submitter. The team also ensures that nightly regression tests are run on all supported platforms, monitors the results of the tests, and opens defects to track regression test failures. A subset of the team does most of this monitoring, however all team members are expected to investigate regression test failures that might have been caused by a source code change they committed.

At times, team members may go inactive for a variety of reasons. The project relies on active team members who respond to discussions in a constructive and timely manner. A team member that is disruptive, does not participate actively, or has been inactive for an extended period may have his or her commit status removed by the Jikes RVM Steering Committee.

Current Jikes RVM Team

Steering Committee

The Jikes RVM Steering Committee (SC) is a small group that is responsible for the strategic direction and success of the project. This governing and advisory body is expected to ensure the project’s welfare and guide its overall direction.

The initial Jikes RVM SC was selected by the Jikes RVM team. Thereafter, to become a member of the SC, an individual must be nominated by a member of the SC, and unanimously approved by all SC members. The goal is to keep the membership of the SC very small. In the unlikely event that a member of the SC becomes disruptive to the process or ceases to contribute for an extended period, the member may be removed by unanimous vote of remaining SC members.

Current Steering Committee