Versions Compared

Old Version 22

changes.mady.by.user Tim Donohue

Saved on

compared with

New Version 23

changes.mady.by.user Tim Donohue

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: adding more background info
Warning

WARNING: This page consists of some rough proppsals / brainstorms on a future direction for the DSpace User Interface(s).

As such, none of this is set in stone, and none of these ideas are (as of yet) guaranteed to occur. If any do begin to gain broad support and momentum from DSpace Steering Group, DSpace Leadership Group, Committers & DCAT, we will inform the community.

Table of Contents

Background Info: Why are we brainstorming this (again) now?

Establishment of DSpace Governance

  • In 2014, DuraSpace helped the DSpace project establish it's first DSpace Steering Group. While initially "appointed", going forward this Steering Group will be elected.  They now control the allocation of funds donated to DSpace (and the DSpace Tech Lead reports to them).
  • In 2015, DuraSpace helped the DSpace project establish it's first DSpace Leadership Group. This Leadership Group is a larger group of community key stakeholders (primarily representing institutions who are also DuraSpace Members who have given money to the DSpace project). The Leadership Group will elect future Steering Group members, and they also represent the broad DSpace community and can vote to accept/reject any proposals from the Steering Group, Committers or DCAT. (NOTE: This group is still in the process of being formed)
  • The Steering Group's role is to "ask the right questions" and make general suggestions for how the DSpace product may wish to move forward. They will work directly with Committers and DCAT to actually help answer those questions (Committers are still the primary DSpace technology decision makers, and DCAT is still the primary DSpace "use case" decision makers).
  • One of the first questions that the Steering Group has asked is essentially: "Why are we shipping DSpace with two User Interfaces again?  Doesn't that split up our resources significantly and make it harder to develop for DSpace? We should think about consolidating to one UI."

Questions this Brainstorm seeks to help answer

So, the question(s) this page is trying to brainstorm include:

  1. Why are we shipping DSpace with two UIs (JSPUI & XMLUI)?  Are there any advantages to doing so?
  2. Should we consolidate into a single UI?
  3. If the answer to consolidation is "yes", what UI should we consolidate under?  Should we just ship with the JSPUI? Should we just ship with the XMLUI?  Or should we build a new, modern replacement UI and ship with that?

Resources & Timeline

  • Assuming we did decide to rebuild/rewrite one of our existing UIs, or even build a new UI, how would we get enough resources (i.e. developers) to do this in a timely manner?
    • If we decided to revamp or build a new UI, the Committers can recommend that to DSpace Steering.  Assuming Steering approves, they would ask the Leadership group to vote on the idea. 
    • If the Leadership group votes to approve the idea, then the Steering & Leadership would seek out the necessary resources to make this happen. 
    • As some of the institutions represented on Steering & Leadership have DSpace developers (or even Committers) on staff, the hope would be that they would donate some developer time to help achieve our goals in a timely manner.
  • When would this happen? What is the timeline?
    • There are NO set timelines for this decision as of yet. It's merely a brainstorm to get a sense of what the developers and Committers feel may be the best direction forward.
    • Tim Donohue will be updating the Steering Group on this discussion as it progresses, and if any timelines are set, the entire community will be informed.

Other Questions?

If you have other questions which are not answered here, please feel free to ask them (either paste them in this section, or email Tim Donohue)

Multiple UIs vs One UI

Why are we shipping DSpace with two UIs (JSPUI & XMLUI)?  Are there any advantages to doing so?

Before deciding on a future direction for the DSpace UI(s), we have to face up to the "elephant in the room". We currently are building, maintaining and supporting two UIs (JSPUI & XMLUI) under a single Committers group.

...

  • One UI technology must rule them all : Can we all come together to decide on a common technology framework that actually will meet all our needs?  Or are there actually separate needs / use cases that warrant the building of distinct UIs (similar to Hydra project)

...

Should we consolidate into a single, out-of-the-box UI?

 

Given the benefits and disadvantages above, one thing seems abundantly obvious: We cannot reasonably expect to continue supporting two UIs with a single Committers team. Or to restate that, it is unreasonable to expect any Committer (who are all volunteers, working at their own jobs) to be well versed enough to support, maintain, develop and review fixes for multiple UIs simultaneously.  This is an obvious misuse of the volunteer resources provided. Each institution has already made their own personal decision on which UI they wish to use, yet we are essentially forcing some institution's developers (e.g. Committers) to also be knowledgable on the other UI (which they never use on a day to day basis).

...

  • Conclusion: Our DSpace Committers group can only reasonably build/support/maintain a single, out-of-the-box DSpace UI.
    • Please note this does NOT state there should only be ONE UI (as noted above there are some advantages to multiple UIs).  It simply states that there will only be one out-of-the-box UI.  
    • If there are enough developers/institutions who see an ongoing need for a secondary UI, they are welcome to build, support and maintain a secondary, optional UI with their own, separate group of developers/committers.
      • A sidenote of sorts: If a secondary "committers group" were to form around a secondary UI, it may someday make sense to "split" the "DSpace Committers Group" into several "sub-teams":  One team in charge of the underlying API / REST API, one team in charge of the primary, out-of-the-box UI, one team in charge of the secondary UI (if any).  These teams would likely have some overlapping members, but they'd each be self-sufficient and more tailored to the needs of each individual sub-modules.
  • Opinions? Please feel free to add +1 / 0 / -1 to this conclusion, and any comments you may have
    • I AGREE: We only should maintain a single, out-of-the-box DSpace UI. If a secondary UI is built (or continues to be maintained), it should be maintained by a separate team of committers / developers (and therefore become a separate project or organization in GitHub).
    • I DISAGREE: We should continue to support/maintain multiple out-of-the-box DSpace UIs with our existing DSpace Committers Team
      • (add your name here, if you disagree with the above conclusion. Feel free to also add additional thoughts/comments)

...