Project developer roles

For the past year, the ImageJ team has been working to better define and communicate the expectations surrounding ImageJ and Fiji. Examples: 1) steps to follow to get your plugin included in Fiji; 2) under what circumstances will a reported bug get fixed. See this slide of my recent presentation for some further examples along these lines.

Recently, I have been working on a script (sloppy work in progress) to generate a table of components including development and maintenance status of the component, and list of parties involved in its development and maintenance. Something like this table, but autogenerated from Maven POMs. The metadata is (in large part) already there—we just need a tool to extract it, format it, and post it to the wiki.

I’d like some advice on how to structure the categories, for both the people involved and the projects being managed. What follows is a summary of my current work in progress, partially inspired by the categories that the Drupal project uses, as well as our current Governance page.

Ideas and thoughts for improvement are very welcome!

Developer roles

  • Founder – Created the project. Does not imply any current participation.
  • Lead – Has decision-making authority: timing of releases, inclusion of features, etc.
  • Developer – Adds new features or enhancements.
  • Debugger – Fixes bugs. Can be assigned open issues to solve.
  • Reviewer - Reviews patch submissions.
  • Support – Responds to questions and issue reports. Keeps the issue tracker organized.
  • Maintainer – Merges patch submissions. Cuts releases.


  • Individuals may fill more than one role.
  • Any role (except founder) can be suffixed with “(interim)” to indicate that a person is filling the role only transiently, until a replacement can be found.

From these developer roles, project status can be inferred, as follows:

Development status

  • Unstable – Project is under heavy development, with unstable API undergoing iterations of refinement.

    • Roles: Developer
    • Version: 0.x
  • Active – New features are being actively developed. API breakages are kept as limited as possible.

    • Roles: Developer
    • Version: >= 1.0.0
  • Stable – No new features are under development. API is stable.

    • No developer role
  • Obsolete – The project is discontinued.

Support status

  • Active – Someone will respond to questions on community channels, and addresses issue reports in the project’s issue tracker. A best effort is made to fix reported bugs within a reasonable time frame.

    • Roles: Support + Debugger
  • Partial – Someone will respond to questions on community channels, as well as to issue reports in the project’s issue tracker. But reported bugs may not be addressed in a timely manner.

    • Roles: Support, but no Debugger
  • Minimal – There is at least one person pledged to the project in some capacity, but not all roles are filled. Response time to questions and issue reports may be protracted.

    • Roles: At least one of Support, Reviewer or Debugger
  • None – No one is pledged to support the project. Questions and issue reports may be ignored.

    • Roles: None of Support, Reviewer or Debugger

Open questions

How to flag projects in need of more help?

  • List the roles marked “interim” under “Help wanted” section?
  • What about roles that are simply missing? Should they be listed?
  • What about roles that are filled, but additional help is desired?

What else am I forgetting here?

  • There are some developer roles which currently don’t factor in to the project status.