Change

Change the software

Change diagram

Defects skip to the top of the development list. All SharedSDS users may vote on enhancement priorities.

Tickets

What follows is in complete compliance with the Governance page:

  • Any change starts with a ticket.
  • There is no difference between a new feature, a change to the documentation, a bug (defect) to be repaired or a new regulation in a jurisdiction somewhere. For inclusion in SharedSDS, it needs a ticket.
  • You must give the ticket a unique one-line name or topic or subject - which can be used to refer to it in conversations with users interested in that change.
  • The ticket description should be short (up to approx 50 words) and summarise why the change is needed. This is a business case to persuade other users to vote it up rather than down!
  • Just because there is a ticket doesn't mean the work gets done. Bugfixes always bypass the backlog. Feature tickets need votes to get to the top of the backlog.
  • As a ticket rises towards the top of the backlog it needs proper specification before a developer can make it happen. Users and developers collaborate to agree on those specifications - which can only deliver a feature which matches the description people voted on! If there is variation, it probably needs another ticket.
  • For a useful ticket you need to specify at least one and preferably more success tests which will pass when the work is done. This is where the rubber meets the road. Success (user acceptance) tests should explain everything to the reader.
  • When the developer has finished work the feature is sent to the users concerned for acceptance testing
  • When everyone is happy, the feature is scheduled for an upcoming release
  • If documentation is required, a ticket must be raised for that as well
  • Anyone can see all the tickets. This is an open source project.
  • You need to be a registered user with a login to write tickets.