DSpace 7 Project Board

Current Project Board

• DSpace 7 Beta 4 project board

Additional 7.x Boards

Boards for all (upcoming) 7.x releases are also visible on GitHub by visiting https://github.com/orgs/DSpace/projects/

Guide to the Project Board

The Project Board represents the workflow we use to complete a specific assigned task. 

Each task is represented by a card which is (usually) either a GitHub issue (or PR, or perhaps both linked together), and comes from one of these GitHub repositories:

• DSpace/DSpace - All backend or REST API tickets/PRs
• DSpace/dspace-angular - All frontend or UI tickets/PRs
• DSpace/Rest7Contract - All REST Contract documentation tickets/PRs

Board vs Milestones

While the Board is oriented towards planning for the next Beta release, it may include PRs with different milestones.  For example, the Beta 3 board may include PRs flagged for milestone "7.0beta4" if those PRs were completed earlier than expected.

In this way, we've chosen to add all active/new DSpace 7 PRs (regardless of milestone) to the current board in order to allow for reviewers to more easily find them.  However, reviewers should prioritize reviewing PRs of the current milestone over any future milestone.

(NOTE: You may also see some temporary milestones which are dates. Those are temporarily placed on issue tickets as the expected/due date of the associated PR.  These date-based milestones may be replaced after the PR is created.)

Board Workflow

To Do → In Progress → Needs Reviewers Assigned → Under Review → Reviewer Approved → Done

1. "To Do": Lists issues that are unclaimed & tentatively scheduled for the current Beta release.
2. "In Progress": Lists issues that are assigned & being worked on (no PR exists yet)
3. "Needs Reviewers Assigned": When a new PR is created, it will be added automatically here. This notifies us that it needs reviewers assigned.  (NOTE: this is where we transition from an issue to a PR.  Therefore, at this time, the original issue card may be removed from the board, and we only track the PR card.)
4. "Under Review": When a PR has reviewers assigned, it is moved to this ready to review stage. It may stay here for some time as the reviewer(s) and original developer work to improve the PR
5. "Reviewer Approved": Once one reviewer approves the PR, it moves here automatically. These are PRs that are close to merging & they may just need one more approval.
6. "Done": Once merged, the PR moves here.
7. "Stalled / On Hold":  If a PR or ticket needs more discussion or stalls (from lack of engagement from the developer), it may be moved here temporarily until it is ready for review again.

Tips for Developers

• When your PR is complete, make sure to link it to the original issue ticket by adding "Fixes #[ticket number]" (or similar) in the description. See the GitHub guide on Linking a Pull Request to an Issue
• After you receive feedback from a reviewer & make updates, make sure to notify the reviewers!  We highly recommend clicking the arrows next the the reviewer(s) name to request a re-review, as this ensures the PR appears back on their "Review requests" list.  See step #7 in the GitHub guide on Requesting a Pull Request Review
• Keep in mind, if a reviewer provides feedback that could/should be done in a follow-up PR, you can open a new issue directly from their comment.

Tips for Reviewers

• Find any reviews assigned to you by visiting: https://github.com/pulls/review-requested
  • This link is available in the black GitHub header from any page. Click on "Pull Requests" → "Review Requests"
• Make sure you submit a review (and not just add comments to the PR). See the GitHub guide on Reviewing proposed changes in a Pull Request
  • We recommend selecting either "Request Changes" or "Approve" on your review as that provides a clear status on the PR.