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...
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
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.
knaddison blog | Morris Animal Foundation
on voting / session attendance
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
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:
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.
knaddison blog | Morris Animal Foundation
Managing Multiple Meeting in COD
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
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.