Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: tweaked guidelines to reference Github instead of SVN

...

  • 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 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, 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 Subversion 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.

...

Once your code is ready, you must make your code available to the DSpace Committers Group for review. This can be in the form of . The easiest way for us to review your code is by submitting a "Pull Request" to our GitHub repository (see Development with Git). However, you may also submit a patch (posted to our DSpace Issue Tracker). Alternatively, you may provide us with downloadable version or read-only access to your code repository. In either case, you should create a new Issue in our DSpace Issue Tracker. This ensures that the DSpace Developers are notified of your contribution, and acts as a place for us to comment on the work or make suggestions for improvements.

...

Info
titleOur recommended way to make code available

The best way to inform us of your code contribution is by entering a new issue into our DSpace Issue Tracker. In that issue you should provide information as to why you feel this code is a worthwhile contribution (e. You should g. describe the bug it fixes or a use case that it meets). You can either submit a corresponding "Pull Request" to our GitHub repository (recommended, see Development with Git) or upload any files/patches to that new issue, or provide links to where the code can be obtainedissue directly. We will then review & comment on your code in that same area (and it will automatically send you an email with our comments).
For Larger Initiatives: If you are building out a much larger project, we will also gladly provide you with a space in our DSpace SVN Sandbox to develop and/or share your work. Just ask us!highly recommend notifying the community of the work early on via an email to dspace-devel@lists.sourceforge.net. This can help find collaborators or get early feedback. We also recommend you develop your project via Git/GitHub, as it provides easier ways to review/collaborate with other developers.

Note
titleKeep in Mind the "Feature Freeze" Deadlines

When the next release of DSpace is getting close, the Committers will set a "Feature Freeze" date, after which no new features/code will be accepted for that release. The reason for this is that the Committers need time to 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 Freeze" 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.

...