Do you face the problem that you need to have a group of people vote on a set of ideas (or projects, demos, award nominations, ...)? In this document, I have three different voting methods that we use at Coda. Depending on what your goals are, one or the other might be a better fit.
The first method of voting is what I like to call Multidimensional Evaluation. It is an excellent fit if you want to rate every item by multiple criteria - e.g., you want a set of
projects evaluated by Creativity, Execution, and Presentation. You will end up with a winner in each category (e.g., Best Presentation) and an overall winner (Overall Best).
The second voting method - $100 investing - addresses a common issue you might face if your judges are not calibrated. Some of them might be more critical and hand out much lower scores on average than others. For example, a common cliche is that engineers are more critical and grade things lower than, say, sales. With the $100 investment method, you give every judge $100 (not real money) to invest across the different projects. They have to spend the entire amount, but it is up to them to give one project a big push or spread it across many.
We use $100 voting a lot at Coda. For example, before a Hackathon, we used $100 voting to have everyone at Coda “invest” in the ideas they wanted to push and get funded.
Sometimes you might face a different problem, and you do not want to identify the best item, but instead, you want to have a group of people come to a decision about which of the items meet a quality bar or not. We use this method for our Coda internal Golden Shovel Award when we evaluate award nominations. We want to make sure every winner has met a very high bar. This is why I call this the Meeting the Bar method (not to be confused with meeting in a bar which can be fun, too). The judges can vote yes (they are strongly supportive), maybe (they are not opposed but not entirely convinced either), no (they are firmly against), or indicate they have no opinion on a particular nomination (e.g., lack of insight or conflict of interest). The tool I built then looks at the votes of the judges:
if a nomination only has Yes, it is clearly above the bar,
if it has only Yes and a few Maybe votes, it is also above the bar, but
if it has few Yes and many Maybes, it warrants a closer look (it did not convince the majority of judges).
If nominations receive mostly Nos or No/Maybe we dismiss it directly, and
we tend to focus almost all our meeting time on discussing controversial nominations that receive Yes and No Votes to see if the Yes faction can convince the No faction (otherwise we do not give the award).
The judges will vote on their “My Judging” page. There, they can leave feedback to be shared back with the team, too (entirely optional).
The moderators can use the Results page to reveal third, second and first place if they want.
Under “All Projects” you will find all the projects and the results
Under “All Feedback” you find all the feedback from the judges and can share that back with the teams
Related work and geeky stuff (feel free to ignore):
There are different ways to implement voting. In this document, I chose to use one table for the projects and one for the votes with a row per vote. That is easy to understand and tweak which is why I chose it here. The vote table scales with number of projects and number of judges though. Coda supports very large tables so this will not be a problem unless you have extremely large number of judges AND projects. There are ways to implement voting with just a single table, for example by storing all votes for a project in a cell of the project table - that requires using undocumented Coda formulas though (hint: Object(), _Merge()). A very smart way to build $100 voting with a single table and without undocumented formulas is used in
