This is a place to view and discuss the short- and long-term roadmap of the software.

It includes bigger pieces of work that require discussion as a group. Feel free to reply to this thread, however where more discussion needs to take place on a particular item, it is linked through to a separate topic. Smaller things like bug fixes are not included in this roadmap - though please do report any bugs you encounter in the Bug Reports category.

(you might also want to look at the overview of this group)

Live / open for feedback


  • Stats and reporting
    • hours volunteered. Making the section available to everyone - what is it interesting/useful for Restarters to see?
  • Repair database. Open up the repair database to be visible and searchable for all users. Needs discussion how to make this useful for everyone.
  • Documentation - all of the documentation needs updating.
  • Improved module integrations.
    • Allow setting usernames in and sent through to Discourse. [might not be needed]
    • Wiki integration: automatic account creation. Existing accounts can be logged in automatically, however new accounts need to be created manually.
  • Repair Data Capture
  • Group Admin
    • Allow group hosts to set other members of the group as a host of their group [currently needs to be done by an Admin]
  • Notifications
    • Probably want to rearchitect this a bit - currently it is simply a way of flagging things that are in a particular state in the data. It is not dynamic in the sense of knowing if a notification has been seen, dismissed, which notifications are new, etc.
  • Localisation. The software is internationalised, in that the framework is in place to incorporate other languages - we just need translations (and a good way of managing them)


  • iCal feeds
  • Stats and reporting
  • Recording non-event based repair (properly recording fixes from places other than community repair - schools, makerspaces, individuals)
  • Favouriting repairs
  • Recording skillshares in the system
  • Closer integration with Repair Directory
  • API
    • fleshing out what can be read via API
    • events feed for groups (also filterable by group tags)
    • Permissioning
  • Including critical raw materials figures in categories and impact stats
  • Refresh of CO2 and weight reference data
    • Involves freezing previous calculations

Long-term / needs discussion

Ideas/features that have been suggested but that need some discussion to iron out if or how they should be taken forward.

  • Investigate migration from Google Maps to OpenStreetMap
  • Participant involvement
    • pre-event
      • advanced registration of devices
    • during event
      • participants contributing data at events
    • post-event
      • feedback from participants
      • collecting narrative stories - testimonials
  • Tracking devices between events/CRM/job management
  • Linking Restarters to individual repairs.
    • gamification for Restarters
  • API
    • Creates/updates/deletes via the API
  • Optimised ‘live event’ view, for projection/display of repairs at events as they happen
  • Skills levels
  • Copy/paste/import device data
  • Dashboard: Customisable per user
  • suggesting where to find repair advice on particular categories
  • volunteer registration during an event, which includes online sign-off of health & safety guidelines
  • specific roles for nationwide organisers (e.g. Norway)
  • automatic analysis of images of model/serial numbers
  • online microtasking to improve data quality
  • other impact stats - e.g. water, critical raw materials
  • chatbot entry of repair information
  • recording repairs from commercial repairers
  • repairers without a group - identify areas with plenty of Restarters but no formal group
  • distribution/federation
    • making it easy to self-host
    • making it easy to customise
    • using e.g. ActivityPub/Micropub to enabled self-hosted instances to federate (events, repair data, etc)
1 Like