Page History

...

• Estimation Process Feedback: DSpace 7 Estimation Process
  • Reminder, these estimates are just to get to 7.0 BETA (not 7.0 Final).  Beta will be the first release that is "full featured" so we are essentially estimating how to make DSpace 7 "full featured".  Once we get to Beta, we will be able to estimate the timeline of Beta to Final, as it may depend on the Community Testathon (to be run once Beta is released) and the results/feedback from that.
  • The estimation spreadsheets don't include all the tasks in our Development Planning Spreadsheet
    • Tim: Correct, we are doing this estimation in stages/rounds.  This is just the first round of estimates (to get familiar with the process).  For the first round, we ONLY included tasks that were NOT flagged as "NEEDS MORE INFO" in the Planning Spreadsheet.  Essentially, we are trying to start with the tasks that seem to have the most "definition" / details.
  • How much time should we be spending to estimate each task (line in spreadsheet)?  For example, if one person spends an hour on each, they may get a more accurate / detailed estimate, but it also would take a large amount of time
    • Andrea said he's been spending about 10mins per task (on average)
    • Ben said he's been spending around the same amount of time
    • Decision: Expectation is that each task estimate takes around 5-15 mins (based on your familiarity with the task/feature).  It's possible some could take slightly longer if you need to dig into DSpace 6.x to see how the feature used to work, etc.  But, you should NOT be spending an hour or so.  You only need to write a few sentences (short paragraph) on the task, and not a very detailed design.
  • Certainty multipliers seem to act unexpectedly for a few people.  "Very Certain" adds in no buffer, and "Certain" adds in a large buffer (up to 2 times).  Should there be a level between them?
    • Reminder from Tim that this spreadsheet was not our design. It was borrowed directly from the Lullabot team (who used it for Drupal estimates), and they defined these multipliers.  Here's the article describing the spreadsheet: https://www.lullabot.com/articles/handling-uncertainty-when-estimating-software-projects
    • Tim not sure if these multipliers were created out of Lullabot team's experience, or if they came from the books that defined the "Wideband Delphi" estimation technique.  Will see if Heather knows or not.
    • We can look into whether these can be tweaked.
    • UPDATE: Mark Wood dug deeper here and noted this on Slack:
      • Re:  uncertainty factors in the Planning Spreadsheet:  to over-simplify, the folks at Lullabot adapted information from McConnell's Software Estimation, so the numbers can be traced back to actual measurements, though what happened to them after measurement is still not entirely clear.  But they weren't just snatched out of empty air.  And software development, being highly creative, is hugely uncertain at times.  As McConnell says, practical estimators are just trying to avoid being off by more than 100%.
  • Overall reminder: This is the first time we are using this process for a large open source project like DSpace.  We've only previously used these spreadsheets for grant estimations, and smaller projects.  There are opportunities to tweak these for our second round of estimates.
• Community/Collection Handles.  Do we display the Handles on the Community/Collection homepages?
  • See: https://github.com/DSpace/dspace-angular/issues/471
  • Main problem: While Communities/Collections have Handles assigned, they will not be "findable" by default in DSpace 7, as the DSpace 7 URL paths are now based on UUIDs.  So, we need a different way to let users know these handles exist
  • All seem to agree, these Handles should be listed as on Community & Collection Homepages
    • However, Initially, we may need to "hardcode" the "handle.canonical.prefix" until this configuration can be provided by the REST API: https://github.com/DSpace/DSpace/blob/dspace-6_x/dspace/config/dspace.cfg#L227
• Revisiting Scripts & processes endpoint discussion (from last week's meeting)
  • One outstanding question, should we "merge" Curation Tasks and Scripts & Processes?  What is the difference
  • Tim: This seems out of scope for DSpace 7. May be a large task.  Also not clear if there is a complete overlap in use cases.
  • However, if we find that Curation Tasks do NOT need their own REST API endpoint, then we could simplify and let them be "kicked off" from the UI via the "Scripts & Processes" endpoint.
  • Andrea: Notes that Curation Tasks do have names & categories that are used at the UI layer to make it easier to select the one you want. 
  • Tim: True, that might imply they need their own endpoint.
  • Decision: Scripts & Processes should move forward as-is.  Need a future discussion around whether Curation Tasks need their own endpoint (or not)