Voting on sessions

Events happening in the community are now at Drupal community events on www.drupal.org.
greggles's picture

I'm tabulating some data from previous conferences to see which system of voting is the best (if any!) and how voting systems were used. This is in part a response to some feedback on our post about the Drupalcon Chicago site and COD where a commenter noted that they dislike a flag style voting.

Copenhagen

Session submission was announced to close on June 20th but in fact closed a week later. Voting was supposed to be the 21st to the fourth, but in fact was from the 5th to the 11th of July. Votes were done as a flag. Here are the count of votes by date:

select count(1), from_unixtime(timestamp, '%d, %c, %Y') from flag_content fc inner join users_roles ur on fc.uid = ur.uid where ur.rid = 5 and fid = 18 group by from_unixtime(timestamp, '%d, %c, %Y')

count(1) day, month, year
70 04, 7, 2010
735 05, 7, 2010
953 06, 7, 2010
854 07, 7, 2010
448 08, 7, 2010
498 09, 7, 2010
724 10, 7, 2010
433 11, 7, 2010

One week is very short so it's hard to draw many conclusions from this. There were 1073 users with the "Drupalcon Attendee" role in the site (purchases made day of or passes given to sponsors make up the difference between that and the real numbers, presumably). Only 238 distinct users voted on sessions. So, any decisions based on the voting was based on the input of less than 25% of the site users.

Looking at when people registered on the site limited down to people who actually attended, it mostly happened early on. Registering on the site is easy, after all.
select count(1), from_unixtime(created, '%u %Y') from users u inner join users_roles ur on u.uid = ur.uid where rid = 5 group by from_unixtime(created, '%u %Y');

count(1) week number year
2 15 2010
318 16 2010
75 17 2010
47 18 2010
52 19 2010
38 20 2010
27 21 2010
30 22 2010
29 23 2010
40 24 2010
69 25 2010
36 26 2010
28 27 2010
42 28 2010
33 29 2010
35 30 2010
61 31 2010
56 32 2010
50 33 2010
5 34 2010

But then when did they make their purchases in ubercart? That was spread out a little more with some peaks when tickets first went on sale,
select count(1), from_unixtime(created, '%u %Y') from uc_orders group by from_unixtime(created, '%u %Y');

count(1) week number year
1 15 2010
224 16 2010
30 17 2010
26 18 2010
25 19 2010
35 20 2010
21 21 2010
53 22 2010
27 23 2010
48 24 2010
170 25 2010
113 26 2010
83 27 2010
107 28 2010
57 29 2010
93 30 2010
116 31 2010
167 32 2010
185 33 2010
29 34 2010
2 35 2010
1 36 2010
5 39 2010
5 41 2010

We can also see that more than half of the orders happened before voting ended. So, only about half of the people who had the permission to vote did vote.

San Francisco

San Francisco is a little trickier because they used the same flag for both voting on sessions and then adding sessions to your schedule. But, we know voting started February 15 and was open until March 1 2 weeks later.

The data shows that voting was left open a little longer than announced which resulted in a ton of new votes.

count(1) day, month, year
2955 16, 2, 2010
1121 17, 2, 2010
1049 18, 2, 2010
371 19, 2, 2010
312 20, 2, 2010
110 21, 2, 2010
933 22, 2, 2010
359 23, 2, 2010
355 24, 2, 2010
561 25, 2, 2010
793 26, 2, 2010
425 27, 2, 2010
682 28, 2, 2010
2227 01, 3, 2010
1090 02, 3, 2010
6 15, 3, 2010

And then apparently on about the 15th the votes were opened up again to indicate which sessions people were going to attend.

Another interesting factor is voting by non-attendees. It's hard to say for sure, but...it appears that about 10,630 votes during the voting period came from registered attendees and another 2349 came from non-attendee users. Put in terms of users rather than votes, 748 attendees voted on sessions and 491 non-attendees voted on sessions.

I'm not sure if that's good or bad. Some folks dislike talking about it as voting and prefer terms of "indication of which session people will go to." However my sense is that conference signups on the website - and especially those while session selection is open - tend to be more advanced users. So, you have to weigh those indications (whether they are votes or signing up to attend the session) against a need to have a balanced session offering with intermediate, advanced and beginner content.

And, when did people in San Francisco purchase their tickets?

count(1) week number - year
650 48 2009
100 49 2009
57 50 2009
68 51 2009
22 52 2009
39 53 2009
5 00 2010
74 01 2010
92 02 2010
117 03 2010
148 04 2010
127 05 2010
154 06 2010
169 07 2010
155 08 2010
185 09 2010
286 10 2010
290 11 2010
435 12 2010
357 13 2010
266 14 2010
539 15 2010
92 16 2010
2 17 2010
2 18 2010
1 20 2010
1 27 2010
1 36 2010

It seems that was mostly well in advance of the voting (week 11).

Comments

where can i ask a question about COD...

mubiesam's picture

Sorry to bother you, but can not find how to ask the question...

Can I create a COD Session as a signup-enabled "Event" Ubercart product type...

You can "Create discussion" in this gruop

greggles's picture

If you've joined the COD group you can "Create discussion" in it for any new topic.

The best place to learn how to setup cod is probably by installing it. If you've already done that, watching http://www.masteringdrupal.com/screencast/getting-started-cod might help.

on voting / session attendance

daniel.a.lopez's picture

I was definitely not surprised to see those numbers. There is not incentive to vote, whats in it for the user? Directly there is no strong motive. Unless there is a benefit to the user such in the case of San Fransisco. Where I would guess (because I do not see the total number of SF attendees) that they had a higher ratio of voters because of the relation to the schedule.

The real mess is that there are many different needs, but only one feature... a flag. Some people are trying to squeeze a need out of a feature that wasn't meant to fulfill that need.

These are all of the user intentions that I can think of relating to the "voting" of the sessions, in order of what I believe what the most users intended on doing or would want to do.

1.) I want to show MY interest in this session.
3.) I want to keep track (personally) of what sessions I want to attend.
2.) I want to show (globally) that I want to attend this session
4.) I want to help show a general interest in this session.

Number four is at the end, i don't think there are many motives or at least not as strong as motives 1-3 as shown from the ratio of attendees and voters from Copenhagen. However it seems as though this is why the flag feature was put in place, to keep track of interest on sessions to plan accordingly.

There is a difference between showing interest in a session and attending a session, and both of these intentions should be fulfilled through different features, with options to enable / disable within the distribution profile settings page.

Ideally It would be laid out in such a way that would encourage participation, interactivity, accuracy of data, and usefulness of the site to the end user and organizers:

A user can show interest in a site, more granularly through a star rating system. The excuse for using binary opinion was to gauge attendance of a particular session, which in my opinion is the incorrect approach, the organizer is gauging attendance with interest, why not make it explicit?

The rating would be labeled something like this: How interested are in in this session?

Immediately next to this, There should be a "I am attending this session" flag

This would then be added to the users schedule. So they can keep track of what sessions they want to attend, or even have the option to make their session schedule public.
The schedule feature can be developed in the future if it hasn't been already.

A users attendance of a session(s) should not be correlated to their attendance of the conference. This would allow the user to schedule first and purchase later. These could be gauged by the conference organizers with maybe a simple report. Listing number of users per session, showing only users who have purchased or marked their account with attending.

I am familiar with distribution profiles and would love to discuss or implement some of these concepts during the sandcamp code sprint if anybody is interested.

I admit I haven't looked through the distribution quite yet, but will be going through it thoroughly tonight. So some of these concepts or features may already have been implemented :)

Summary:

COD / organizers should be not be reliant on votes far as weighing attendance.

There should be a definite distinction between attendance and interest to allow for accurate data.

A user should not be required to attend the conference to “Attend a session”

quick update on chicago

greggles's picture

The voting is now closed. Here is the distribution of votes:

mysql> select count(1), value from votingapi_vote group by value limit 10;
+----------+-------+
| count(1) | value |
+----------+-------+
|     1255 |    20 |
|      688 |    40 |
|     1118 |    60 |
|     1788 |    80 |
|     3653 |   100 |
+----------+-------+

We won't know things like percent of users who voted until the final registrations are done. I'm actually really impressed by this. It shows that votes in a fivestar scenario are sometimes the right thing to do.

The labels on the stars were:

  • I have no interest in this session
  • I would probably not attend this session
  • I might attend this session
  • I would probably attend this session
  • I totally want to see this session

This does conflate the question of "attending the session" and "I think this session should be accepted" - I'm not sure exactly what the best practice is there, but daniel.a.lopez has raised a lot of interesting points above.

Managing Multiple Meeting in COD

nereeves's picture

I work for an association and sometimes we have meetings that overlap. We are about to upgrade our Drupal to the newest version - and have been told the COD does not support multiple meetings happening at the same time. Is this true? Any tips on how to manage multiple meetings at the same time would be most helpful!

Thanks!

This isn't particularly

c4rl's picture

This isn't particularly on-topic, but the traditional session scheduling feature of COD allows to create rooms and time slots, then assign a session per-room, per-time slot. So in the event that you aren't actually holding two sessions in the same room at the same time, this functionality is accomplished rather easily.

Furthermore, you could simply create two duplicate rooms with slightly different names to override this limitation if indeed you have two meetings in the same room at the same time. This pattern tends to exist at Drupalcamp and Drupalcon BoFs.

Event Management Systems

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

Hot content this week