Versions Compared

Old Version 67

changes.mady.by.user Tim Donohue

Saved on

compared with

New Version 68

changes.mady.by.user Tim Donohue

Saved on

Key

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

...

  • 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 Licensing of Contributions section below.

...

Note
titleWhat are we reviewing for?

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:

  • The code is stable and has no stability or security concerns
  • The code is properly using existing APIs, etc.
  • The code is not too specific to one institution's local policies or workflows. (I.e. we will review the code to ensure it looks to be generally useful to most institutions, or configurable enough such that others can change it to match their own local policies/workflows)
  • Any third-party tools/libraries used by your code have compatible open source licenses. See #Licensing Licensing of Contributions

3. Reworking Code (if necessary) & Next Steps

...

  • Curly braces must be on new lines.
  • Source files must have a copy of the copyright Duraspace notice and BSD license at the top (see #Licensing Licensing of Contributions below). Also take a look at Copyright and Licensing.
  • You must use 4-space tabulation.
  • 'else' should be on a new line. 'else if' stays on one line.
  • Users of the Eclipse IDE can have eclipse do the formatting automatically using this profile: - Dspace-eclipse-format.xml. See the Eclipse section below for details of how to apply this profile.

...