...

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.

Development Proposals

Place for proposals about underlying development and 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.

To include your proposal here give it the label "developmentproposal".

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 Including 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.

...

To include your proposal here give it the label "organizationalproposal".

...