Page tree

Versions Compared

Key

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

...

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 in a Pull Request, we will work to find it reviewers/testers.  By default, every Pull Request requires at least two separate reviewers (or testers), ideally from two different institutions. Some small PRs (usually 200 lines or less) might be flagged as "1 Approval", meaning only one person needs to review that work.  During review/testing, other developers may contact you via GitHub to discuss any feedback they 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 others notice).

Info
titleCode Review Timeframe

The timeframe of a code review will vary, based on how much time the Committers core developers have. Smaller changes may be reviewed within days, while larger changes/features may take many weeks to do a full review. All Developers/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
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 well commented (e.g. has JavaDocs or TypeDocs)
  • The code follows our Code Style Guide (only required for DSpace 7.x and above)
  • The code provides Unit and/or Integration Tests (see Code Testing Guide) (required for DSpace 7.x and above)
  • 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 of Contributions

...

After the code review & feedback, interested developers/Committers may help you to rework the code (if needed). They'll also provide you with next steps on getting the code into DSpace. If it can be accepted immediately, it will be. If not, we'll try to help figure out the best route forward.

Info
titleHow you can help speed up the process

As our developers/Committers are all volunteers, they don't always have the time to rework code changes for you. If you want your code change accepted in a timely manner, please offer to make the changes yourself (otherwise your patch suggestion may wait in a "holding queue" until someone has enough time to work on any necessary fixes).

...

Note
titleCommunicate, Communicate, Communicate

If you are unsure of next steps, please let us know by adding a comment to your issue/PR in the Issue TrackerGitHub. Communication is absolutely necessary to ensure that we can help you rework anything that needs reworking. If we don't hear from you, we'll assume you are hard at work. So, if you've run into issues, please let us know! If, locally, you don't have the time or expertise to do the rework that is necessary, also let us know. We can try to locate a community developer to help out, and/or ask both the Committers Team and the DSpace Community Advisory Team if they know of any interested developers with time to spare.

...