x

Main chapters

  1. LimeSurvey Cloud vs LimeSurvey CE
  2. LimeSurvey Cloud - Quick start guide
  3. LimeSurvey CE - Installation
  4. How to design a good survey (Guide)
  5. Getting started
  6. LimeSurvey configuration
  7. Introduction - Surveys
  8. View survey settings
  9. View survey menu
  10. View survey structure
  11. Introduction - Questions
  12. Introduction - Question Groups
  13. Introduction - Surveys - Management
  14. Survey toolbar options
  15. Multilingual survey
  16. Quick start guide - ExpressionScript
  17. Advanced features
  18. General FAQ
  19. Troubleshooting
  20. Workarounds
  21. License
  22. Version change log
  23. Plugins - Advanced
 Actions

The bugtracker and git

From LimeSurvey Manual

This article should help developers on the LimeSurvey when resolving issues.

General process outline:

  1. Bug reported by a user in Mantis
  2. Bug assigned to a developer (by the developer or someone else)
  3. Bug fixed and a PR (pull request) made at github.com
  4. Mantis ticket status changed to ready for code review, Assigned To can remain to be the developer that fixed the issue
  5. When creating the PR, please assign reviewer (DenisChenu or gabrieljenik for bugs, developer suggested by Github for features - suggested reviewers are based on git blame data)
  6. If the code review fails, reviewer puts comments in the PR what needs to be fixed
  7. After successful code review, quality assurance tests and verifies the bugfix/feature
  8. If testing fails, quality assurance puts comments in the Mantis ticket
  9. Finally if all is well, quality assurance merges the PR and code gets published with a new version
  10. Mantis ticket status changed to resolved and later closed

This method of working should allow for efficient bug fixing with multiple developers.

Please respond on what you think of this process, or what should be changed.