Thursday, September 23 (PR Create Date): every PR wanting to get into 7=
.1 should be created. Any created by this date are "guaranteed" in 7.1. Any=
thing after may not be included in 7.1.
Sept 23 - Oct 14 (PR Final Reviews): code review=
s & PR updates
Thursday, Oct 14 (PR Merge Date): every PR ge=
tting into 7.1 must be merged.
Monday, Oct 25: Internal/Early release goal. If possible=
, we'd like to release 7.1 in late Oct.
Monday, Nov 1: Public Release Deadline. 7.1 must be a=
nnounced/released by this date.
Ongoing/Weekly tasks:
Tackle/Claim issues on 7.1 board (starting with=
"high priority")
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.1 Project Board - Assign tickets t=
o developers & assign PRs to reviewers.=20
Paid (by DSpace project) developers must keep in mind priority. If new =
"high" or "medium" priority tickets come in, developers should move effort =
off of "low" priority tasks.
Volunteer developers are allowed to work on tickets regardless of prior=
ity, but ideally will review code in priority order.
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")
New Feature development process for 7.1
For brand new UI features, at a minimum, the UI ticket=
should contain a description of how the feature will be implemented=20
If the UI feature involves entirely new User Interface interactions or =
components, we recommend mockups or links to examples elsewhere on the =
web. (If it's useful, you can create a Wiki page and use the Balsamiq wireframes plugin in our wiki)
Feature design should be made publicly known (i.e. in a meeting) to oth=
er Developers. Comments/suggestions must be accepted for TWO WEEKS,=
or until consensus is achieved (whichever comes first). After that, silence is assumed to be consent to move=
forward with development as designed. (The team may decide to extend=
this two week deadline on a case by case basis, but only before the two we=
ek period has passed. After two weeks, the design will move forward as-is.)=
This does mean that if a UI feature is later found to have design/usabi=
lity flaws, those flaws will need to be noted in a bug ticket (to ensure we=
don't repeat them in other features) and fixed in follow-up work.
For brand new REST features (i.e. new endpoints or major change=
s to endpoints), at a minimum we need a REST Contract prior to dev=
elopment.=20
REST Contract should be made publicly known (i.e. in a meeting) to othe=
r Developers. Comments/suggestions must be accepted for TWO W=
EEKS, or until consensus is achieved (whichever comes first)=
em>. After that, silence is assumed to be consent to move =
forward with development. (The team may decide to extend this two week dead=
line on a case by case basis, but only before the two week period has passe=
d. After two weeks, the design will move forward as-is.)
This does mean that some REST features may need future improvement if t=
he initial design is found to later have RESTful design flaws. Such f=
laws will need to be noted in a bug ticket (to ensure we don't repeat them =
in other features) and fixed in follow-up work.
REST API Backwards Compatibility support
During 7.x development, we REQUIRE backwards compatibility in the REST =
API layer between any sequential 7.x releases. This means that the 7.=
1 REST API must be backwards compatible with 7.0, and 7.2 must be compatibl=
e with 7.1, etc.=20
However, deprecation of endpoints is allowed, and multi-step 7.x releas=
es may involve breaking changes (but those breaking changes must be depreca=
ted first & documented in Release Notes). This means that it's al=
lowable for the 7.2 release to have changes which are incompatible with the=
7.0 release, provided they were first deprecated in 7.1. Simil=
arly, 7.3 might have breaking changes from either 7.1 or 7.0, provided they=
were deprecated first.
After 7.x development, no breaking changes are allowed in minor release=
s. They can only appear in major releases (e.g. 7.x=E2=86=928.0 or 8.x=E2=
=86=929.0 may include breaking changes).
I=
ssue Triage process for 7.1
Overview of our 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.1, 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 feature is badly broken or missing/not work=
ing. These tickets must be implemented first, as ideally they must=
be resolved prior to 7.1. (Keep in mind however that priorities may =
change as the 7.1 release date approaches. So, it is possible that a "high =
priority" ticket may be rescheduled if it is a new feature that cannot fit =
into 7.1 timelines.)
"medium priority" label =3D A feature is difficult to use, but mostly w=
orks.. These tickets should be resolved prior to 7.1 (but the 7.1 =
release will not be delayed to fix these issues).
"low priority" label =3D A feature has usability issues or other smalle=
r inconveniences or a non-required feature is not working as expected. =
; These tickets are simply "nice to have" in 7.1. We'll attempt to fi=
x 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.1 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".
On Hold Topic=
s
Will we need subminor Release Numbering for 7.x?=20
Should we potentially have subminor (e.g. 7.0.1) releases to fix major =
bugs or security issues? Or would those need to wait for the next min=
or (e.g. 7.1) release?
Considering regular, scheduled releases instead of feature-based releas=
es?=20
Every quarter (3 months) release a new 7.x. Feat=
ures will be implemented in priority order, but not necessa=
rily guaranteed for a specific release.
Discussing Release Support now that 7.0 is out..=20
Should we propose to Committers / Governance a change of policy to the =
"most recent two (2) major releases"? This would mean that we move to=
only supporting 6.x and 7.x.