VOLUNTEER HELP APPRECIATED: (Maureen & Bram at DCAT have been a=
sked to help with this) Final review of Test Plan spreadsheet=
. Ensure all feedback/bug reports are captured in GitHub Issue tickets =
(most already should be), so that we can prioritize, etc
UNTESTED TASKS:
(DSquare Technologies is helping with this)DSpace 7 Security Analysis (In our=
dev process, we have been running automated security checks, but an extern=
al analysis would be nice)
(Needs volunteer) DSpace 7 Performance Analysis (In our dev process, we've =
done past performance analysis, but more "real life" checks would be nice)<=
/li>
:tick: (COMPLETED) Final analysis of Accessibility Results (from Deque)=
- assigned to Tim Donohue =20
Reminder: Open Repositories starts in just over 1 week (Monday, June 7)=
Setting an (estimated) release date for 7.0=20
Assuming only "high priority" tasks (~80hrs of estimat=
ed dev work). "Medium priority" tasks become "nice to have", but many=
/most will be delayed to 7.1
Team availability after OR2021 during June/July/Aug? Could we rel=
ease by July 15? Aug 1? Aug 15? Sept 1?=20
Aug 1 release date (maybe Aug 8)
July 15 every PR merged
June 24 - July 15 reviews (Art out week of July 12, Ben out week of Jul=
y 5, Tim out week of July 5, Andrea out June 23-July 2)
June 24 every PR created (high priority mainly) - Guaranteed in 7.0, an=
ything after may not be in 7.0
(30 mins) Planning for next week=20
Review the Backlog Board - Are there any ticke=
ts here stuck in the "Triage" column? We'd like to keep this column a=
s small as possible.
Review the 7.0 Project Board - Assign tickets t=
o developers & assign PRs to reviewers.=20
Priority should be kept in mind here. If new "high" or "medium" priorit=
y tickets come in, developers should move effort off of "low" priority task=
s. Reviewers/testers should also concentrate effort on "high" or "med=
ium" priority PRs.
To quickly find PRs assigned to you for review, visit https://github.com/pulls/review-requested (This is =
also available in the GitHub header under "Pull Requests =E2=86=92 Review R=
equests")
Issue T=
riage process
Overview of our 7.0 Triage process:
Initial Analysis: Tim Dono=
hue will do a quick analysis of all issue tickets coming into our Backlog Board (this is where newly reported issues will=
automatically appear).
Prioritization/Assignment: If the ticket should be considered =
for 7.0, Tim Donohue will categorize/labe=
l it (high/medium/low priority) and immediately assign to a developer to fu=
rther analysis. Assignment will be based on who worked on that feature in t=
he past.=20
"high priority" label =3D A required 7.0 feature is badly broken or not=
working. These tickets are considered "blocking" and must be reso=
lved prior to 7.0 final.
"medium priority" label =3D A required 7.0 feature is difficult to use,=
but mostly works. These tickets should be resolved prior to 7.0 f=
inal (but the 7.0 release will not be delayed to fix these issues).
"low priority" label =3D A required 7.0 feature has usability issues or=
other smaller inconveniences or a non-required feature is not working as e=
xpected. These tickets are simply "nice to have" in 7.0 final. =
We'll attempt to fix them as time allows, but no guarantees are made.
Detailed Analysis: Developers should immediately analyze assig=
ned tickets and respond back within 1-2 days. The developer is expected to =
respond to Tim Donohue with the following=
:=20
Is the bug reproducible? (If the developer did not understand the=
bug report they may respond saying they need more information to proceed.)=
Does the developer agree with the initial prioritization (high/medium/l=
ow), or do they recommend another priority?
Does the bug appear to be on the frontend/UI or backend/REST API?
Does the developer have an idea of how difficult it would be to fix? Ei=
ther a rough estimate, or feel free to create an immediate PR (if the bug i=
s tiny & you have time to do so).
Are you (or your team) interested in being assigned this work?
Final Analysis: Tim Donohue =
will look at the feedback from the developer, fix ticket labels & move =
it to the appropriate work Board. If it is moved to the 7.0 Project Board, then the ticket may be immediately assigned b=
ack to the developer (if they expressed an interest) to begin working on it=
.=20
If the ticket needs more info, Tim Donohu=
e will send it back to the reporter and/or attempt to reproduce the bug=
himself. Once more info is provided, it may be sent back to the deve=
loper for a new "Detailed Analysis".
=
Security / Performance Tests
Brainstorming options for security testing & performance tes=
ting. How do we want to handle both of these prior to 7.0 final?