Developers / DCAT Meeting before OR16 on Mon, June 13, 2016

Who is invited?

• All Committers,
• All DSpace Community Advisory Team (DCAT) members,
• Any other interested DSpace developers or technology-savvy individuals

If you don't fall into one of the above categories, you are still welcome to attend. However, be warned that discussion will likely get very technical at times (which is why we recommend you be a developer or have a technology background).

Logistics

• Day: Monday, June 13th, 2016 (Workshop / Tutorial day)
• Time: 9:00am - 12:30pm (with a break at 11am)
  
  • NOTE: This working meeting is considered a "workshop", so it is listed as part of the Workshop/Tutorial day schedule.
• Where: Lloyd A in Lloyd Institute on campus
  • OR2016 venues map: https://drive.google.com/open?id=1K1FspyeZLbl7ty1-5vK1q1h6DMI&usp=sharing
  • Campus map: https://www.tcd.ie/Maps/assets/pdf/tcd-main-campus.pdf

Agenda

9:00am : Introductions

• Name, Institution, How are you using DSpace?, How have you customized DSpace (or anything you'd be willing to contribute back)?
• Assign a note taker!

9:15 - 11:00am :  New UI Initiative , Decision Making / Collaboration

• DSpace New UI Initiative and Roadmap to DSpace 7
  • How we got here (DSpace UI Prototype Challenge , also see YouTube playlist of video updates)
  • Why Angular 2? (Risks vs opportunities)
  • Proof of concept: https://github.com/DSpace-Labs/angular2-ui-prototype
  • DSpace 7 proposed architecture (overview), including necessary REST API enhancements
  • How you can help / How would you like to help
    • How can DCAT support this initiative / provide feature suggestions/expertise?  How can other developers / institutions get involved?
• DCAT, Committers and Steering/Leadership: How we collaborate and make decisions together
  
  • Streamlining the ways to get new features approved and into DSpace
    • Which features should be pushed up for DCAT or Steering approval first?
  • Moving the code through technical approval process. Are there ways to streamline?
  • Streamlining the ways we share expertise / contributions between and within our groups?

11:00 - 11:15am : Coffee Break

11:15am - 12:30pm: DSpace-CRIS (and other topics)

• DSpace-CRIS discussion (led by Michele Mennielli and Andrea Bollini of Cineca)
  • Why the Steering Group sees this topic as important (Jonathan Markow)
  • Demo / Overview of DSpace-CRIS functionality
  • Brief overview of DSpace-CRIS data model / technical differences with out-of-the-box DSpace
  • Discussion: Where does the repository end and the CRIS begin?
    
    • What features of DSpace-CRIS are of high interest to DSpace users in general?  Author Profiles?
    • Are there parts we feel should be include in "out of the box" DSpace?
    • Are there parts we should encourage distributing separately as "extensions" or "add-ons"?
    • How can we work together to move this effort forward?
• Time permitting, we may also select one or more topics from the list of "Additional Topics of Interest" below.

Additional Topics of Interest (time permitting)

What would YOU like to hear about or discuss?  Please add your ideas to this list, and if we have extra time during our meeting, we will pull topics from this list to discuss.

• Creating a community for repository managers/super users to share expertise.
  • Our developer meetings and DCAT discussions are often task-oriented and future-focused (next software release).  
  • We do not currently have a forum for exploring existing system features (facets, workflow, permissions, etc) and discussing best practices around those features.
    • Comment (from Tim): There may be direct opportunities to start some of this in the design / implementation of the new User Interface. I would love to have feedback on feature best practices and UI design. This is a great opportunity to build the UI we need/want, and not just recreate what we already have.
  • A forum such as this could be a useful way to nurture future project contributors.
• The DSpace 6 Service API - What is now possible
  • The new service API introduced hibernate into DSpace.  What capabilities does this infrastructure enable (performance tuning, diagnostics, etc)?
• Metadata Authority
  • The metadatavalue table contains 2 columns: authority and confidence.  
  • What is the intended behavior of these fields?  Are these fields behaving as expected? (note: the intended behaviour is documented in the Data Model section here: Authority Control of Metadata Values#DataModel)
  • There has been some recent discussion of text vs URL's in metadata.  Could these fields provide a solution to the issues being discussed?
• Usage Statistics - how to deal with inaccuracies such as bots.
  • NOTE: For folks interested in this topic, there are a few OR16 sessions related to improving DSpace statistics:
    • Tues @ 11am: Developer Track 1: Platforms and Analytics (see specifically "I can haz robot" by Joseph Greene)
    • Thurs @ 11am: Panel 5: Usage Statistics (Includes comparisons/discussions of DSpace, Eprints and Minho statistics engines)
• Overview of the process of how new code gets into DSpace; not just the GitHub-specific process, but what discussions take place, the whole workflow, and where people can help to move code through that process.
• GPG-Key-Signing: We sign our releases but we didn't build a chain of trust yet. Let's cross sign our keys to catch up. More info here (you'll need to print something before-hand if you actually want people to be able to sign your key).

Sign Up to Attend!

If you're planning to attend this meeting, please add your name to the sign up sheet below. This will help us better cater to content to the audience type. In addition, don't forget to officially REGISTER for this workshop from the OR2016 site (as that is the official registration form)

Sign Up Sheet - Will Be Attending  (If you are only able to attend part of the meeting, please note your approximate arrival)

1. Tim Donohue
2. Maureen Walsh
3. Jonathan Markow
4. Pascal-Nicolas Becker
5. Mariya Maistrovskaya
6. Terrence W Brady
7. Susan Borda
8. Hardy Potting
9. Graham Triggs
10. Roeland Dillen
11. Andrea Schweer
12. Ivan Masár
13. Ignace Deroost
14. Bram Luyten (Atmire)
15. Andrea Bollini (4Science)
16. Michele Mennielli
17. Margaret Vail

Possibly Attending / Unsure

• (add your name here)

Meeting Notes

(in progress)

Q: Can you talk more about the backend? (Ivan)

A: Regular Angular 2 backend.

Q:Performance (Pascal)

A: Only used for clients with JavaScript turned off (Google Scholar, explicitly in browsers)

Q NoScript extension (Mark)

A: Roeland uses it, works, requires JavaScript turned on. Does more than just turning off JS per domain, like XSS protection. (Roeland)

Q: REST API completeness, missing features

A: UI developers are keeping a list. We’ll discuss whether current REST is adequate or needs a rehaul.

Q: Road map for the UI? (Monika)

A: Will be covered later in the presentation

Q: Theming support (Ivan)

A: Bootstrap theming (there was a successful prototype of changing Bootstrap variables from admin UI). CSS (SASS). Very HTML-like templates. (Tim, Art)

Q: Performance (Kim)

A: The frontend (Angular server-side rendering)  can run on a separate machine. Possibly multiple different frontends in front of a single DSpace instance.

Q: Theme per collection/community/site – we should support out of the box. (Ivan)

Q: Angular components (?)

A: Can be moved around, HTML-like snippets. (Tim) Creating new components is simple (Art)

Q: Architecture diagram? What components are being used? (Pascal)

A: Tomcat, Node.js, don’t need to be on the same server

Q: What other components are there in the UI? E.g. SASS compiler?

A: SASS->CSS, TypeScript->JS, NPM does that. Node implementation of SASS compiler.

Q: Next directions for JS? (Terry)

A: E.g. React. (Tim) First page rendering on the server really speeds up the user experience. (Art)

Q: Browser compatibility? In relation to server-side rendering. (Kim)

A: HTML and CSS

Q: Backward compatibility (e.g. input form declaration file) (Terry)

A: Migration or backward compatibility will be considered. To be decided, still just a POC. (Tim) New formats are an opportunity to solve some current issues. Important that we tested that we can use JSON to dynamically adapt submission form. Opens customizability options. (Andrea)

Q: Would be nice to have separation of visualization vs. validation in input forms. User can play with it since it’s on the client side. (Roeland)

Q: services, DI - related to Java? (Ivan)

A: Services are a TypeScript concept, underlying components, conceptually map well to Java. Services take care of communication via REST, components render the data. Services vs. modules allows for an abstraction layer – e.g. only services could be adapted to DSpace 7 vs. 8 REST API.

Q: Considering using other Spring components (security, auth)? (?)

A: We seem to be gradually moving more toward Spring. Needs volunteers.

Q: We’re behind with DSpace 6, took year and a half, what about DSpace 7? (Pascal)

A: We’ll also likely take a year and a half for DSpace 7. Then hopefully get back to yearly releases.

Q: List of missing features so that devs can implement them? (Mark) List of desired features? (Monika)

A: Currently have list of use cases, will transform to list of features.

Q: compatibility of the UI with older version of DSpace (5, 6) while developing it for DSpace 7

A: Will be considered, we’ll see how hard it will be as we’re adding new features.  (Tim) We can have different builds of the UI for DSpace versions, the architecture of Angular makes it easy (Art)

Q: Security support (Pascal)

A: still as declared, we’ll support JSPUI and XMLUI for 3 years as declared. We'll deprecate JSPUI and XMUI in DSpace 6, remove in 7.

Q: REST development vs. UI development? (Terry)

A: Opportunity to work in parallel.

Q:  Why do people not upgrade? (Monika)

A: DSpace 5 moves the data for you (even skipping DSpace versions), huge step in ease of upgrade for instance which don’t have many code customizations. DSpace 6  has new configurations system, will allow to build migration of config options. Pascal talks about potential upgrade problems (configuration changes, Java version requirements).

A: If we say 6.0 is last stop for XMLUI and JSPUI, what if @mire wants to add new features to XMLUI? (Bram)

Q: XMLUI may be refactored as a separate project out of DSpace and available separately as an addon, it just won’t out of the box.

Q: We’re deprecating old UIs now, but we don’t have the new UI ready yet. Is this what we want to do? (Graham)

A:  The goal is to go from 3 UIs to 1, less effot yo support them (Mark). Cocoon has a max. Spring version, you can’t upgrade Cocoon beyond that. (Art)

Q: How does the UI development work in terms of work organization (Sprints) (Monika)

A: Can take Sprint as a unit of work. Can view it as task-oriented (develop a feature). Time-based (can dedicate a week). Multiple models possible, even in parallel.