Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Always provide us with as many details as you can. A paragraph description is good, but a few paragraphs with some sample use cases is even better. A single sentence description is often very hard to work with, and we may need to ask you for more information before we understand what you are asking for.
  2. If you have use cases, or local needs, describe them to us. Use cases really help developers understand why this feature is important, and use cases may also help us locate other institutions with similar needs.
  3. Expect that we probably will need to ask you a few questions. Even with detailed descriptions/use cases, chances are we'll need to follow up with you later for a few more details, or to make sure we understand exactly what you are asking for. So, please be willing to respond to questions, or requests for more details. Anytime someone comments on your newly created issue, you should receive an email from the Issue Tracker system.

2. Advertise your Request to Others & Help

...

Us find a Volunteer Developer or Two

All of our DSpace Developers are volunteers. Let's repeat that: All of our DSpace Developers are volunteers. What this means is the core DSpace Development Team (i.e. the Committers) don't always have control over how much time they can spend on developing new features for DSpace. In many cases, the Committers can only work on new features which are of interest to their local institution/university.

...

  • If you have a local developer who has time to work on this feature, let us know when you submit the issue (or add a comment later). If a local developer can already work on the issue/feature request, all that we may just need to happen is that we'd need to approve the code (see ContributionGuidelines, for details on our DSpace Code Approval/Acceptance processprocesses).
  • If you know of other institutions with similar needs, tell them to "vote" for your issue request in the Issue Tracker, or add their own use cases/support as comments. Also, if any of them have a developer with time to develop the feature, let us know!
  • If you aren't sure if other institutions may have this need, you can promote your issue by sending an email to 'dspace-general' or 'dspace-tech' mailing lists, asking for others' feedback. Hopefully, others can add comments/suggestions or even point us all in the direction of an interested volunteer developer.
  • Even if we cannot find an interested developer in the Communitycommunity, the DSpace Committers will review your request and see if any of them has one or more Committers have time to devote towards the work. In some cases, a Committer may be able to convince their institution of the importance of the new feature (again, sample Use Cases use cases are helpful to convince institutions of a feature's importance)

3. Respond to the Formal Review of your Request (

...

as necessary)

Each Feature Request is guaranteed to get a formal review by at least one of two groups (possibly both):

  1. The DSpace Committers - They review every feature request or bug report that comes into the system, often in weekly Developer Meetings. Note: Because of occasional backlogs, it is sometimes possible there may be a delay of several months before your request will get a formal review.
  2. The DSpace Community Advisory Team - They review and request additional feedback about any new feature request. This is a team of Repository Managers (or similar) who provide additional feedback to the Committers on new features.

After a formal review, a comment will be added to your request (it will also generate an email to you). This comment will detail the results of the initial review, along with any questions that came up. If you have time, please respond to these questions, or encourage others to do so. These questions are often asked to help us determine more about the request, so that we can ensure we have a common understanding.

...

  1. We may have a backlog of requests, and just haven't gotten to a formal review yet.
  2. We may need to find a developer (or committer) who has time to develop this feature. In these cases, if we can locate other institutions who may be interested, that can often help in the search for a volunteer developer.
  3. We may be waiting for the answer to one or more questions posed in earlier comments. If we need more clarification, we can let you know.
  4. It's also possible that there are one or more developer(s) actively working on the feature, but that the work is not yet in a "completed" state.

5. Once your Request is Accepted into DSpace

If your request is formally accepted into DSpace, you'll receive an email as soon as we "Close" or "Resolve" the request in our Issue Tracker. At that point in time, the Issue Tracker will also be updated to state which version of DSpace this new feature will be released in.

Once that version of DSpace is released, your name (and a link back to your initial feature request) will appear in our Version History section of our DSpace Documentation. You will also be added to our list of all known DSpaceContributors. This is our way of ensuring you receive recognition for your contributions to DSpace!

If You Want to Contribute Code

...