Actions

Project ideas for GSOC 2011

From LimeSurvey Manual

Revision as of 13:58, 16 February 2022 by C schmitz (talk | contribs) (Text replacement - " enclose="div"" to "")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Welcome

Welcome Google Summer of Code Student aspirants (:razz:)

This page lists project ideas developed by the LimeSurvey Community. These tend to be areas that will get the most support as projects since they have been developed by people who know the project and what it needs the most. However, if you have your own idea for a project discuss your awesome idea with us in our forums, mailing list or at #limesurvey on irc.freenode.net. Then submit your proposal. Good Luck (:biggrin:)


Project ideas

Central participants database (User panel)

Develop a central 'participants' database for LimeSurvey that can be used as a central registry of participants between surveys. The database should allow

  • adding/removing of users along with flexible data to store related information for users
  • simple copying of user-information to individual survey token tables
  • ability to link user entries with survey responses if the linked survey was not unanimous (UUIDs?)
  • ability for survey participants to register in the panel
  • ability to update the flexible user data from collected results
  • a 'do not email' blacklist to allow people to automatically unsubscribe
  • data ownership features for multi-user systems - allow different LimeSurvey users to 'own' different participants

Skills

Database and PHP coding, CodeIgniter

Difficulty

Moderate to high - the coding would be relatively simple, but will entail complex database relationships

Probable mentors

Jason Cleeland


Port the LimeSurvey front-end to CodeIgniter

LimeSurvey is still written using old procedural code. We want to take the next step into the future and use a MVC-framework name CodeIgniter and port the whole application to this new framework. However proting the whole application is too much for one students. That is why we will split the task into smaller ones. This particular task deals with porting the front-end of LimeSurvey to CodeIgniter - this means all the parts that can be seen by the average survey participant:

  • Survey taking
  • Public statistics
  • Central landing page

During the rewrite you will be prompted also to encapsulate certain functions to objects where easily doable and it makes sense - we do not want you to rewrite everything. Since you are only working on a certain part of LimeSurvey and other students will port the back-end (=administration) of LimeSurvey you will be required to coordinate your coding with the other students.

Skills

OOP experience in PHP and experience with a PHP framework like CakePHP or CodeIgniter are definately a must. You should get busy with LimeSurvey as early as possible. Students can raise their chance to get accepted by showing off according knowledge about LimeSurvey inner workings.

Difficulty

If you fulfill the requirements above the difficulty in this task is to gradually modernize an application with a modern coding approach while resisting the natural urge to rewrite everything at once. Our mantra to modernizing the application is that the framework is just laying the new fundaments while the fance walls can be built later. So we lay the fundament first and make it stable, then we build new walls (See also the LimeSurvey roadmap )

Probable mentors

Carsten Schmitz (c_schmitz)

Thibault le Meur (tlemeur)


Port the LimeSurvey back-end (administration) to CodeIgniter

LimeSurvey is still written using old procedural code. We want to take the next step into the future and use a MVC-framework name CodeIgniter and port the whole application to this new framework. However porting the whole application is too much for one student. That is why we will split the task into smaller ones. This particular task deals with porting the backend of LimeSurvey to CodeIgniter - this means all the parts that can be seen by an administration user.

During the rewrite you will be prompted also to encapsulate certain functions to objects where easily doable and it makes sense - we do not want you to rewrite everything. Since you are only working on a certain part of LimeSurvey and another student will port the front-end (=administration) of LimeSurvey you will be required to coordinate your coding with the other student.

Skills

OOP experience in PHP and experience with a PHP framework like CakePHP or CodeIgniter are definately a must. You should get busy with LimeSurvey as early as possible. Students can raise their chance to get accepted by showing off according knowledge about LimeSurvey inner workings.

Difficulty

If you are a very good PHP coder (and fit the demanded skills above) then the main difficulty in this task is the sheer size of it. The administration consists of a great number of different screens and functions which need to be ported. If you don't manage to port all of it then at least the unported parts still have to be working - still best would be if you manage to do the whole administration.

Also the difficulty in this task is to gradually modernize an application with a modern coding approach while resisting the natural urge to rewrite everything at once. Our mantra to modernizing the application is that the framework is just laying the new foundation while the fancy walls can be built later. So we lay the foundation first and make it stable (your task in the administration), then we build new walls (See also the LimeSurvey roadmap )

Probable mentors

Carsten Schmitz (c_schmitz)

Thibault le Meur (tlemeur)


Implement a modular authentication framework

The idea is to design and implement a modular authentication "framework" for LimeSurvey as well as some authentication modules. The Authentication framework will define the API each authentication plugin must (or may) implement and propose basic methods that can be used by plugins (for instance how to store the plugins parameters in DB, how to display a form using the survey template). A plugin will be responsible to implement, for each particular authentication backend, specific methods (some mandatory, some optionnal) such as: user authentication, user provisionning, user rights, ...

Currently authentication is only used for the survey-administration GUI and not the participants interface (tokens are used for this). With the new authentication framework it will be possible to define several authentication backends and use some of them for participants-authentication.

The generic authentication framework must define the following services:

  • User authentication: this interface must return the identity of the authenticated user if authentication is successful.
    • Authentication may not always be based on a simple user/password form, so the proposed framework must be generic enough to enable authentication based on other schemes (using any numbers or interaction-pages between the server and the end-user or any other contextual parameter such as Referrer, session variable...
  • User provisionning:
    • when activated on the survey administration interface, an authentication module might be able to create a newly authenticated user into the LimeSurvey internal DB (which is required for setting the user rights on the platform). The newly created user can be assigned a default profile or a per-user profile (queried from an external database).
    • when activated on the participants interface, the authentication module will provision the token table of the correspoding survey // alternatively the general-purpose cross-survey participants-database as described in the above GSoC idea.

The already existing authentication schemes will be ported to the new framework (internal-DB and Web server authentication delegation) and at least a new one will be implemented (openID, CAS, Shibboleth).

Skills

PHP, SQL, CodeIgniter, Authentication protocols (openID, CAS, LDAP-bind, ...)

Difficulty

Medium

Probable Mentors

lemeur (Thibault Le Meur)

Want to know more

Please read the FAQ about this project


Rewrite and extend the conditions in LimeSurvey

AddNewCondition1.png

Rewrite the conditions engine that will let survey administrators design, store and evaluate conditions. Conditions must be implemented in such a way that they can be used in several features such as question branching (survey logic), assessments, quotas, ...

This projects will at least end up with:

  • A working GUI to design complex conditions:
    • several atomic conditions can be combined by AND or OR logical operators and will support for grouping conditions with parentheses
    • an atomic condition representation can be
<left operand> <operator> <right operand>
    • an atomic condition editor will implement
      • several operators (equality, inequality, string-comparisons, numerical-comparisons, regexp),...
      • meta operators surch as 'Not displayed'
    • left and right operands can be answers from previous questions, or a static values. It should be extensible so that we are able in the future to use more complex operand such as the result of a specific function (for instance the sum of some previous integer questions)
  • A working DB storage backend using a string in RPN (Reverse Polish Notation) to describe each condition
  • The evaluation of conditions for the question branching feature.

Skills

PHP, CodeIgniter, JQuery and User Interface Design Skills

Difficulty

High

Probable Mentors

Thibault Le Meur (lemeur)

Carsten Schmitz

Want to know more

Discussion about the LS2 conditions engine is an interresting start. Note however that the task will be easier this year because of the existing conditions engine and the stable database layout of LS1.


Custom Report Generation

The task is to make a module which will generate custom reports. Module should be able to do these things(at least) :-

  • Creating various types of reports i.e. using tables, pie charts, graphs and bar-charts to name few.
  • The resulting charts and other illustrations should be easy to read and understand, and should include the ability to export into standard office suites.
  • Reports can be general or survey specific.
    • General in the sense that it should show basic findings of a general survey graphically like number of users completing the survey, average time taken to complete the survey, average number of correct responses etc.
    • Survey specific results should also be addressed properly e.g. how many users choose first option as there answer of a particular question, how many users didn't answer a specific question etc.

Skills

OOP experience in PHP and experience with a PHP framework like CakePHP or CodeIgniter, jQuery. Strong mathematical background will help!

Difficulty

Moderate

Probable mentors

Carsten Schmitz (c_schmitz)


Adding new questions/subquestions and groups dynamically

Currently in LimeSurvey once a survey is activate we can not

  • Add or delete groups
  • Add or delete questions
  • Add or delete subquestions or change their codes

The idea is to cover these shortcomings. And in addition, all those participants who have already taken that survey must also be notified about the changes.

Skills

Experience with a PHP framework like CakePHP or CodeIgniter and knowledge of inner working of LimeSurvey is must!

Difficulty

Moderate

Probable mentors

Carsten Schmitz (c_schmitz)


Extend the use of assessments

Assessments are used a lot at LimeSurvey but currently this feature only covers very basic needs. Users have asked for some additional assessment features, unfortunately most of them can't be implemented until we start saving assessment results at the database instead of calculating assessment scores at runtime.

So the first step is to extend the database layout of LimeSurvey and add a new table for storing assessment results. Once this is done advanced features can be implemented such as:

  • Export assessment results when exporting survey data
  • Include assessment results at confirmation emails
  • Extend statistics to include information about assessment results such as max score, min score, mean score, standard deviation, ...
  • Connect quotas and assessments so that assessment results can be used to screen users at the beginning of a survey.
  • Enable assessment scores at conditions so that a condition like "Show question X if <assessment_score1> > 10"

Skills

PHP, MySQL, CodeIgniter, JQuery and some basic User Interface Design Skills

Difficulty

Medium

Probable Mentors

Carsten Schmitz (c_schmitz)


NEW Rebuild the database frontend using CodeIgniter

During last years GSoC, a database frontend was developed using CakePHP. LimeSurvey has since decided to switch to the CodeIgniter framework. As such, last years work needs to be ported to CodeIgniter.

All documentation from last year is available at here aswell as the source of the developed CakePHP modules which can be found here - the plugins market with dbse.

The final project has to comply with the API developed last year, changes have to be discussed.

Skills

PHP, SQL, Object oriented programming & design patterns, CodeIgniter, CakePHP

Difficulty

Medium, Main challenges will be database abstraction and automatic generation of sql code out of survey structures.

Probable Mentors

Maarten Tielemans (ttielu)

Pieter-Jan Speelmans (MrP001)


Idea template

Describe the idea here in general terms

Skills

Explain what sort of coding skills would be needed for a student to implement this project

Difficulty

Explain the level of difficulty involved

Probable Mentors

Put your name (and tag) here if you are willing to mentor a student for this idea


More information

Getting started

Check out our 'Get started' page for setting up the development environment, coding standards, and all the other important stuff that you need to know before the real fun begins!

Frequently Asked Questions

Check out our GSoC FAQ page.