Page History

...

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 weeks/months before your request will get a formal review by the Committers. However, it is worth noting that your request will be immediately emailed to the 'dspace-devel' listserv, tickets' mailing list. where individual developers may provide immediate feedback before the formal review takes place. So, you may not need to wait that long for immediate response, or even for a developer to volunteer to work on that feature.
   • For more information on which issues the Committers are planning to review in their next meeting, see the currently posted agenda on the Developer Meetings page. Please Note: The Committers always review issues in the order they are received. However, as noted above, all new feature requests are emailed to 'dspace-devel', so if there is immediate interest amongst developers, you may find you will receive more immediate feedback and/or questions.
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.

...

• Please be sure to share your plans with the DSpace community on the 'dspace-devel' list (or via one of the weekly Developer Meetings) before embarking on any sizable development effort. This will ensure you achieve your goals in a way that is consistent with the DSpace architecture and plans of the rest of the community. This will minimize the chances of a scenario where you have invested a large amount of time and effort into a body of code that does not fit in with the DSpace architecture or the consensus of the community, meaning that you need to spend further time refactoring your code or worse, 'forking' the code.
• Develop incrementally; try and implement and contribute a basic form of your feature as soon as possible, rather than aiming to implement a complete and 'polished' solution. This will help ensure you're on the right track with regards to the rest of the DSpace community and platform. The sooner your code is part of the core code base, the less time you will have to spend 'chasing' the main code base, i.e. keeping your changes up-to-date with that core code base.
• Obtain the DSpace code using GitHub. This will make code management much easier. It's very simple to do; see Developer Guidelines and Tools and Development with Git.
• Read Code Contribution Guidelines to ensure you are following DSpace conventions. This page also gives you a sense of the DSpace Code Approval processes.

...

1. Add a comment to the Feature/Improvement you plan to work on, letting us know you will work on it.
2. If you'd like more input on the feature/improvement, or potential requirements, post your questions and/or plans as a comment as well.
3. Make sure your developer is following our Code Contribution Guidelines. If you have questions about any guidelines, or want some early feedback/suggestions from developers, please get in touch with us on the 'dspace-devel' listserv. We'd be glad to help make suggestions on ways in which to implement the new feature, and the earlier you get in touch, the earlier we can give you feedback on whether there's anything you may need to change before we can accept it as part of out-of-the-box DSpace. See also the Code Review Process on the Code Contribution Guidelines page.
4. If you run into any "gray areas", ask questions! If it's a development issue, contact the Developers via the 'dspace-devel' listserv. If it's a policy issue or requires feedback from Repository Managers, get in touch with the DSpace Community Advisory Team, as they can help you query the community for feedback and/or provide you with their immediate opinions

...