Page tree
Skip to end of metadata
Go to start of metadata

A Proposal for an Improved Review Workflow for New Feature Requests.

Proposal for closer collaboration between Committers and DCAT when it comes to reviewing & locating resources to implement new feature requests.

Overview

This proposal details a way in which DSpace Committers and DSpace Community Advisor Team (DCAT) can potentially work together to locate any additional resources / information that is necessary to complete feature requests which are deemed "high priority".

Background

As most may be aware the DSpace Community Advisor Team (DCAT) formally began its activities in January 2011. If you haven't done so already, you can read more about the group in the announcement that went out. Basically, the DCAT group is focused on helping to review new feature requests in JIRA and promoting community-wide discussions on those requests in an attempt to find more interested developers to work on specific new features. During the DCAT meeting on Feb 1, 2011, DCAT continued to evolve the review process – and refined a proposal on how the DCAT and committer/developer group could work together.

Current DCAT Review Process

DCAT aims to identify the most compelling new feature requests and keep the work on those moving forward. That is NOT to say DCAT wants to set committer/developer priorities. On the contrary, DCAT wants to better understand the status of the new feature requests, particularly for those they determine that have broad appeal/high priority for the community.

The way the process is working now is the following:

  1. DCAT reviews one new feature JIRA issue per week as selected by an individual DCAT member.
  2. That DCAT member proposes a DCAT rating of the issue – ranking the issue's appeal to the community (broad, narrow, etc.) and priority (high, medium, low).
  3. After the rest of DCAT vote on the rating recommendation, the comments are posted to the JIRA issue and a DCAT member may make inquiries with the original JIRA requestor and/or the assignee.
  4. If the request does not have an assignee or if the assignee does not believe it highly likely they can complete the request for the next release, the DCAT would hold a community-wide discussion about the request. The purpose of the discussion would be to confirm the interest in the community and to seek new developer resources to work on the issue. The hope is not only that more new features can be developed, but new developer resources will find ways get involved.

Proposal: How DCAT and the committers/developers can potentially support one another

If a "higher priority" feature requests are assigned in JIRA already, DCAT may ask about its latest status (if unclear from JIRA comments). This is not to put pressure on the current developer, but rather a way for DCAT to determine if the Committers/Developers require additional community support for the feature in question. For example, if the current assigned developer finds he/she is unable to get to the work or the work has become a lower priority to their institution, then DCAT can go to the larger community and lobby for additional help in developing this new feature (perhaps even from a non-Committer, if no one else is available to build the feature).

In addition, if the feature request is complex or has several dependencies, DCAT may wish to know what committers/developers would recommend as the next steps (more community discussion defining requirements, solicitation/formation of project teams, identification of dependencies, etc.). Again, DCAT will attempt to bring these requests to the larger community, in order to try to help the feature request move forward (if possible).

Therefore, we are looking for a way to help 'bridge' communication between DCAT and the Committers team.

A few routes come to mind:

  • Option A: For feature requests deemed "higher priority", DCAT could request updates via a comment in JIRA. At that point in time, the current JIRA assignee could provide a basic status update (if possible), or a request for what additional help/support is necessary (whether in terms of requirement definitions, or developer time). DCAT would then attempt to provide whatever support is necessary.

AND/OR

  • Option B: For feature requests deemed "higher priority", DCAT could request updates via a comment in JIRA. At that point in time, the Committers as a whole group would re-visit that JIRA request in their next meeting. As a group, the Committers would then determine if additional support from DCAT (or the community) is necessary. Once a decision is made, one of the Committers will add a response to JIRA either requesting more support, or providing a brief status update.

This process is still evolving – and we are looking for feedback on how it can improve. Again, the interest is to have productive discussion about specific feature requests, determine their priority, get an realistic/accurate assessment of where they sit in the work queue and solicit more developer help from the broader community where necessary. The goal is to help the current Committer development/release process, and not to create further "red tape".

Please add your comments to this page, or email Tim Donohue or Valorie Hollister with your suggestions.