Page History

...

Given this, it only seems reasonable to also conclude:

• Conclusion: One 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.
    • +1  Tim Donohue
  • 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)

What makes a good UI (framework)?

...