Page MenuHomePhorge

Add polling functionality in Roundcube
Open, LowPublic

Description

In order to be able to organize meetings with a large group of people, it might be useful to have some kind of polling functionality embedded somewhere into Roundcube.

Some food for thought:

  • Provide a management interface for the poll admin(s).
  • Provide priorities to the possible choices (no binary decision).
  • Implement a deadline until the users can express their preferences (notify indecisive users when the poll is about to expire).
  • Embed the resulting event into the users' calendars.
  • Enable access to persons outside the Kolab environment through an invitation mail including a link, a username and a password for the poll. Notify them like the internal users over their mail and send them a calendar file.

Projects can be found here.

Details

Ticket Type
Task

Event Timeline

I read the problem space as Kolab users not being able to tell when attendees are available, and/or when attendees would prefer a meeting be held.

This doesn't necessarily make it impossible for Kolab users to schedule meetings with larger groups of people, however. I reckon the idea is to make it more convenient for Kolab users, though.

Organizing a meeting with a large number of fellow Kolab users is facilitated through the use of Free/Busy information. For at least that scope, I believe we have sufficiently intuitive functionality included in the product.

This enhancement request would then facilitate scheduling meetings with attendees not already Kolab users, or attendees for which the Free/Busy information is not available. Free/Busy information for these external, third parties not being available could be considered a separate problem to address.

It is also important to attempt to recognize what sort of "meetings" this would facilitate. If it were a corporation's team meeting in a physical board room, than the question is likely more along the lines of "when employees are available", while a marketing webinar may lean more toward a "when would attendees prefer". We may need to consider separately, meetings with a physical proximity requirement, from meetings with a mere Internet-connectivity or phone-available type of requirement.

As for user stories, we'll need to explore what those need to be, illustrated by the following:

  • John wants to schedule a meeting with Jane and two other people, and suggests either 09:00 and 15:00 on Monday.

    John's calendar may now need to contain two occurrences of the same meeting, with both marking John as "busy" (John is the organizer).

    John's agenda being blocked for all suggested occurrences of the meeting may not accurately reflect John's needs at that point, but not blocking John's agenda may cause John to be scooped from underneath his own meeting.
  • Jane marks the 15:00 meeting as preferred.

    Jane's calendar may now need to either mark and unmark occurrences of the meeting as tentative (becomes declined or accepted?).
  • Awaiting the other people's responses, agendas are being blocked while the balance may still tip in favour of one of the other occurrence.
vanmeeuwen lowered the priority of this task from 60 to 20.Mar 10 2016, 3:47 PM
vanmeeuwen raised the priority of this task from 20 to Low.Mar 28 2019, 8:13 AM