Versions Compared

Old Version 10

changes.mady.by.user Tim Donohue

Saved on

compared with

New Version 11

changes.mady.by.user Mark H. Wood

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Fixed a broken internal link

...

  1. No incomplete features on the "Master Branch", ever.
    • If you are in-progress on a feature, develop it in a branch or fork (see Developing Development with Git) and submit a Pull Request once it is ready for feedback. (NOTE: You need not necessarily wait until it is complete to create the initial Pull Request, since Pull Requests can be updated easily. But, obviously the Pull Request should not get merged until the code is complete and approved.)
    • All DSpace GitHub projects (i.e. not just DSpace/DSpace) should follow this rule. If there is major rework to be done, create a branch or fork to do the work, and then submit it via a Pull Request.
    • Clarification: Although this rule may seem strict, it is meant to point out that a broken "Master" branch is an urgent issue. There may be situations where breaking the Master branch temporarily may even be necessary. However, we should make all attempts to keep breakage to a minimum (or forewarn the Committer team if anticipated). Temporary breakage is OK, but longer-term breakage (a few days or more) can negatively affect us all.
  2. All new features must have documentation before merging into the Master Branch.
    • New features/improvements should not be merged/committed into the Master Branch until there is some minimal documentation (minimal documentation includes documenting all configuration options). Ideally, they should also come with usage documentation (i.e. examples of how to use the feature, how to configure the feature, etc.) This will help us all ensure that Documentation is ready by the time we get to the next release, and hopefully lessen the time that any one person has to spend cleaning up or rewriting documentation.