Page History

...

• (30 mins) General Discussion Topics
  1. (Quick note) Posted 7.1 deadline to DSpace Release 7.0 Status
  2. (DRAFT) Policy/Procedure on Designing DSpace 7.1 New Features
     1. For brand new UI features, at a minimum, the UI ticket should contain a description of how the feature will be implemented
        1. 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)
        2. Feature design should be made publicly known (i.e. in a meeting) to other Developers.  Comments/suggestions should be taken in for at least TWO WEEKS.  After that, silence is assumed to be consent to move forward with development.
        3. This does mean that if a UI feature is later found to have design/usability 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.
     2. For brand new REST features (new endpoints or major changes to endpoints), at a minimum we need a REST Contract prior to development.
        1. REST Contract should be made publicly known (i.e. in a meeting) to other Developers.  Comments/suggestions should be taken in for at least TWO WEEKS.  After that, silence is assumed to be consent to move forward with development.
        2. This does mean that some REST features may need future improvement if the initial design is found to later have RESTful design flaws.  Such 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.
  3. Follow up on REST API design for "Entities Projections"? : https://github.com/DSpace/RestContract/pull/165
     1. Noted last week the design flaws.  However, PR was pending.  Based on the PR, are there ways to quickly correct the design flaws and/or create a ticket for future work?
  4. (Other Topics?)
• (30 mins) Planning for next week
  • Review the Backlog Board - Are there any tickets here stuck in the "Triage" column?  We'd like to keep this column as small as possible.
  • Review the 7.1 Project Board - Assign tickets to developers & assign PRs to reviewers.
    • 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 priority, but ideally will review code in priority order.

...