Page History
...
- 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. It 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.
- 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 (see also Development with Git). This will make code management much easier. It's very simple to do; see Developer Guidelines and Tools.
- Read Code Contribution Guidelines (this page) to ensure you are following DSpace conventions. This will ensure your code is more likely to be immediately accepted as part of out-of-the-box DSpace.
- Ensure that any third-party tools/libraries that you plan to utilize are released under compatible open source licenses. See the #Licensing of Contributions section below.
1. Make your code available
...
| Note | ||
|---|---|---|
| ||
When the next release of DSpace is getting close, the Committers will set a "Feature FreezeContribution Deadline" date, after which no new features/code feature submissions will be accepted for that release. The reason for this is that the Committers need time to review & stabilize the current code before the next release can be completed. Make sure to check the Next Release Status page for details on when the next "Feature FreezeContribution Deadline" is – if you are submitting your code too close to the "Feature Freeze" date, it may unfortunately need to wait until after the next version of DSpace is released. Patches which fix bugs will also generally be considered until much closer to the final release date. Please note that bug fixes are still accepted after the "Code Contribution Deadline", as they will help to stabilize the upcoming release. |
2. Code Review Process
Once the code is made available, the Committers Group will take time to review the work and provide feedback/comments. Usually, one (or more) committers who are interested in this work will contact you and discuss any feedback we have, and whether or not there would need to be some general changes before we could accept it. Some patches/features are readily accepted (because they are stable and look good), others may require more work (if there are concerns or issues that Committers notice).
| Info | ||
|---|---|---|
| ||
The timeframe of a code review will vary, based on how much time the Committers have. Smaller patches changes may be reviewed within days, while larger patcheschanges/features may take many weeks to do a full review. All Committers are volunteers and only have a small amount of time to provide to the project in a given week. We will make every effort to get back to you with feedback within a few weeks. But, if you haven't heard anything, feel free to ask! |
| Note | ||
|---|---|---|
| ||
When we review your code, we are mostly ensuring it generally follows our Code Contribution Standards. However, there are a few other things we generally check for:
|
3. Reworking Code (if necessary) & Next Steps
...
Overview
Content Tools