Page History

...

• REST API discussion:  Reminder to all (self included) which endpoints can support which methods
  • Reviewed notes in agenda above, Per our Contract README: https://github.com/DSpace/Rest7Contract/blob/master/README.md#use-of-the-http-verbs-and-http-response-code
  • We may need to revisit the decisions in these two recent PRs:
    • https://github.com/DSpace/Rest7Contract/pull/79 (Community & Collection Logo).  Should PUT/DELETE just use /bitstreams/<:logo_uuid>? (as Logos are Bitstreams!)
    • https://github.com/DSpace/Rest7Contract/pull/80 (Collection Item Templates).  Should PATCH/DELETE just use /items/<:itemtemplate_uuid>? (as Templates are Items!
  •  For Item Templates, there are many Item features which don't apply (Item Templates cannot have bundles/bitstreams – they are just metadata – and they cannot be withdrawn or made private)
    • Andrea noted these are long standing flaws (since DSpace 1.x) in the Java API layer. Currently, there's no Item Template object, so at the Java layer it's possible to add bitstreams to Item Templates or withdraw them...however, in DSpace 6.x and below we just didn't enable those features in the User Interfaces.
    • After discussion, we feel it might be good to create a separate `/itemtemplates/` endpoint which is specific to these Item Templates.  However, if that proves difficult/complex, we could just use the `/items/` endpoint (as described) and delay these improvements to DSpace 8.x (as they are existing flaws in 6.x anyways, and we could similarly hide them from the UI layer in 7.x).
  • For Logos, they seem similar enough to Bitstreams that we should be able to use the /bitstreams endpoint
  • ACTION: Tim will create tickets to suggest the necessary changes to these REST Contracts.  Discussion can move to those tickets & (if needed) can be brought back up in future meetings
• Revisiting our Code Review processes for PRs
  
  • Up until now, all PRs require two approvers
  • As we've seen, this provides good feedback, but can cause review/implementation delays if only one reviewer can be identified in a timely fashion
  • This issue was brought to Steering Group.  Recommendation is to consider allowing for single reviewers for smaller / more obvious PRs, with option of that reviewer asking for an additional reviewer if they find something requiring additional feedback.
  • Some brainstorms from the team:
    • Should we default to one approver required per PR, but optionally request a second approver for more complex PRs?
      • Tim notes that REST Contracts likely need to default to two approvers. We've already seen issues where we accidentally approved contracts that didn't align entirely with our own design (see previous discussion). More eyes is really better when it comes to Contracts
    • Should we default to two approvers (like currently), but optionally flag specific PRs as needing just one approval (if they are minor, obvious, or simply quick bug fixes with ITs)?
    • Team agrees we should try an approach and see how it works. Can always change the approach if something isn't working.
    • Tim prefers the latter approach for now (two approvers is default, but can make exceptions for specific PRs).  We can try that out for a few weeks and see what it's impact is.  If it's too much work or not working well, we could try the one approver approach in future.
  • ACTION: Tim will figure out a way to flag PRs as "one approval" needed.  That way we can visually see which ones are smaller & easier to move along.  Developers who add PRs to our review list can optionally flag their own PRs as "one approval" to note to Tim (and others) that they feel it just needs one person.
• Other topics were moved to next week. Ran out of time.

...