What is a Proposal?

"Proposals" definition: Proposals detail ideas, brainstorms or potential solutions to a known issue or problem in the code, community or process. Proposals may recommend changes we could make that may help us resolve issues we've encountered in the past. A few examples: a proposal could recommend accepting or adding a new technology, changing an API, or changing how we interact as a team or plan new releases of the software.

"Special Topics" versus "Proposals"

• Special Topics are higher level topics/questions/problems which need to be addressed or discussed. They may include some details or background about the problem domain, but should not suggest any particular solutions to the problem.
• Proposals should present potential solutions to the problem. One Special Topic (e.g. "How can we better handle Preservation Metadata?") may result in many Proposals (e.g. "Option #1", "Option #2", "Combo of Option #1 and #2", etc.)

Overview: Adding a new Proposal

This page is a place to post new proposals for review by DSpace Community and/or Developers. New proposals can recommend any sort of change to solve an existing or perceived problem/issue. A few examples: a proposal could recommend accepting or adding a new technology, changing an API, or changing how we interact as a team or plan new releases of the software.

To add a new proposal:

1. Please create a sub-page for the details of your proposal. In your details you should describe the reasons behind your proposal. Your proposal need not be flushed out completely – even initial ideas are welcome, especially if they can start to answer some basic questions:
   • Why do you feel this will help DSpace Software or our Community as a whole?
   • What problem(s)/issue(s) are you trying to solve?
   • How do you feel your proposed solution could resolve these problems/issues?
2. Once your proposal is ready for review/comments, add a link to your proposal page and brief description in one of the categories below.
   • Feel free to add additional proposal categories below if your proposal does not fit into an existing category.
3. Announce that you have a new proposal posted for comment/review. The best way to announce this is via either a mailing list, or at a DSpace developers meeting (if it is a technology proposal)
4. It is recommended to add a "last updated" date below so that people know if you've made significant updates to your proposal

To comment on an existing proposal

1. Visit the proposal page and either comment on the proposal directly, or add your thoughts on the "discussion" page.
2. Please keep comments constructive. Give reasons why you agree/disagree to help us improve upon the proposal.

Organizational Proposals

Place for proposals around improving how we as a community or as a development team are organized.

No proposals at this time.

Release Cycle/Process Proposals

Place for proposals about improving our normal DSpace release cycle (e.g. how frequently we release a new version, how we plan those releases, how we communicate those releases, etc.).

• TimeDrivenReleaseProposal - Proposal to move to regular, recurring releases on a schedule. (Reviewed on 10 March 2010 during DSpace Dev Mtg – see page for comments)

• ReleaseAdvisoryTeamProposal - Proposal to create a Release Advisory Team to help support the Release Manager during DSpace releases, and also provide opportunities for more immediate feedback from repository managers or other non-techie community members. (Reviewed on 10 March 2010 during DSpace Dev Mtg – see page for comments)

• On DSpace Development - Stuart Lewis's thoughts after his experience as 1.6.0 Release Coordinator. Some of Stuart's key points are quoted below, but read his full blog entry for more background on these ideas. (Reviewed on 10 March 2010 during DSpace Dev Mtg)
  1. On Release Coordinator role: "Being a developer myself has no doubt helped in this process, but I don't think the role needs to be held by a developer."
  2. On Choosing Release Coordinator: "Traditionally the release coordinator has been chosen once the previous release has been made. It would be more effective if they were chosen three or four months earlier. This would give the benefit of them learning the ropes from the current release coordinator, but more importantly the current and next release coordinators could work together to help decide what is in and out of scope for the current and next versions"
  3. On Decision Making Process: "How do we get ... extra input? It would be impractical to involve the whole community in all decisions, so we need a representative sample of the entire community to for a team who can make these decisions. The team needs to include developers, users, and Duraspace staff. A team of 8 to 12 should ensure enough breadth of experience whilst remaining small enough to be effective. Duraspace would decide the Duraspace members, and elections could be held for the two categories of other members (developers and users)."
  4. On Committership: "if a community decision-making team existed, then the committers group could change its direction. At the moment being a 'committer' is conflating the original meaning that is the rights to add code to DSpace in our code repository, with the role of decision-making. If this decision-making role is given to the newly formed group, then being a 'committer' goes back to the traditional meaning. We can then open this group up to anyone who asks for (and needs) commit rights."
  5. On Release Schedule: "I'd like to see us move to more regular releases, and to keep to only those minor fixes and features for minor releases."
  6. On Other Roles: "We need to find good ways of encouraging more contributions from the community, playing to people's strengths and interests. If all 700+ institutions could donate a small amount of effort, must think what we could do!"

Technology Proposals

Place for proposals about underlying technology changes in the software (e.g. API changes, architecture/design changes, etc.). Technology changes may need to be sub-categorized if we start to receive many different levels of proposals.

• Easier Upgrade Process
  • Basic, high-level proposal for a simple upgrade script: DS-456
  • Build a simple way to verify if a DSpace upgrade was "successful": DS-439